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róiskola:  € 
felkészülés valami 
komolyabbra 


Szorgos munkával telt a január, s ez meglátszott a januári lapszám februári 
postázásakor is. Ahogy régi munkahelyemen mondták: ha jön a tanfolyam, 
még meghalni sem szabad az oktatónak. Nemhogy mással foglalkozni! Már- 
pedig tanfolyam lett, ismét sikerült megmozgatnunk ötven-hatvan embert. 
Nagy szám ez? Hát bizony a Magyarországon fellelhető informatikusok-rend- 
szergazdák-programozók számához képest elenyésző. 

Mint már annyiszor az elmúlt két évben, most is oknyomozásba kezdtem, va- 
jon mi a jelenség oka. Megkérdeztem például huszonvalahány közeli ismerő- 
sömet, milyen szaklapokat olvasnak, miből tanulnak. Több, mint 5090-ban 
az válaszolták, hogy ,nem érünk mi rá ilyesmire"! Nem érnek rá olvasni! OLl- 
taniuk kell a mindenütt felcsapó lángokat! 





Hadd meséljem el egy régi élményemet: pár évvel ezelőtt főállású oktatóként dolgoztam egy hazai 
CTEC oktatóközpontban. Napi 8, (néha, esti oktatással együtt 10) heti 40, nem ritkán havi 180 óra 
telt oktatással. Hajtás közben nem éreztem sem fárasztónak, sem unalmasnak a munkát - de semmi 
másra időm nem jutott. Se olvasás, se gondolkodás. Mígnem egyszer, 1998 magasságában kisírtam 
egy amerikai konferenciautat magamnak. Nem emlékszem már, mi hajtott, azon túl, hogy még füg- 
gőleges állapotában megmászhassam a World Trade Centert, de tény, hogy annyira az ügyön voltam, 
hogy idegességemben eltévesztettem a repülőgép indulásának napját, ennek folyományaképpen to- 
tálkárosra törtem az autómat, majd a roncsot hátrahagyva egy nap késéssel, és egy szál fogkefével 
elrepültem a Windows 2000 Technology Week rendezvényre Seattle-be. 

Ez is kalandosnak tűnik, de mi volt ez ahhoz képest, hogy egy teljes hétig kiestem az örökös mun- 
kából! Napközben tanulás, délutántól CSÖND. Se munka, se barát, se email, se telefon, se SMS - csak 
a csönd. Szinte megrohantak a gondolatok! Nem így kéne tanítani, sok mindent nem úgy kéne szer- 
vezni, így és így lehetne mindent egy picit jobban csinálni... 

Szinte kívülről (és távolról) láttam saját munkámat, és benne a nagy-nagy céltalanságot. Hazatérésem után 
akut konferencialátogatóvá váltam, és például 2000-ben (aranyév!) írd és mondd ötször szöktem meg kon- 
ferenciaalibivel a világ elől. Az az egy-egy hétnyi gondolkozási idő megváltoztatott engem. Lettek céljaim, 
és lett NetAcademia, és lett tech.net, és lett NATE. Ennyit tesz, ha valaki időnként leteszi a poroltót. 


Nemrégiben végigültem Soczó Zsolt kollégámnál az ASP.NET tanfolyamot. Mint azt az msdev listán 
megírtam, a második napon elveszítettem a fonalat, de ismét nyertem három napot gondolkodásra. 
Meglepve tapasztaltam, hogy ha kisebb mértékben is, de a tanfolyam is kiragadott a napi robotból. 
Kevesebb gondolatom támadt ugyan, mert esténként csak visszaváltoztam irodakukaccá, majd apu- 
kává, de az a pár óra is élményszámba ment. Az ugróiskolával ezt az élményt, ennek egy falatkáját 
szeretnénk megmutatni mindenkinek. Adjon egy kis gondolkodási időt önmagának! Nem hosszú időt, 
nem marketingblablára, hanem az elvekre. Minden napi munka végezhető vak tapogatódzás mentén, 
de megfontolt cselekvéssorozattal messzebbre jutunk. 

Sok olyan informatikus van, aki ezt a vezércikket sem olvassa, mert nem ér rá. Nincs öt perce. Nem- 
hogy egy hete! A fokozatosság jegyében a NetAcademia felkínálja az Ugróiskola rendszert, ahol az elő- 
re kiadott tematika mentén ki-ki arra az alkalomra jön el, amelyik anyagát saját munkájában hasznos- 
nak látja. A maximum másfél órás elfoglaltságot mind árban, mind időbeosztásban úgy pozicionáltuk, 
hogy a főnöktől sem engedélyt, sem anyagi támogatást kérni nem kell. Részletek a 44. oldalon. 


Fóti Marcell 
" főszerkesztő 
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.NET kalauz: 


tanuljunk .NET-et! De hogyan? 

Aki nekilát .NET-et tanulni gyakran úgy érzi magát, mint egy dzsungelharcos: vágja maga 
előtt a bozótot, küzd nagyon, de valójában fogalma sincs merre tart. Ez a kis útmutató 
azoknak nyújt segítséget, akik szeretnék élvezni a .NET fejlesztések előnyeit, és minél 
gyorsabban használható tudásra szeretnének szert tenni. 


Farkasokkal táncoló Advanced File Share Prope... [/ 


A C Normal share 

ÖV: TESZ)! zer 
Jobbról is, balról is körbejártuk már a fürtszolgáltatást, szinte minden 
beállítást ismerünk, csak még erőforrásokat nem hoztunk létre egy szálat sem. 
Ezt a fejezetet kizárólag e témának szenteljük. 


(7 Share subdirectonies 
TT Hide subdirectory shares 


anee 
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A trust leleplezése 


Egy Windows 2000 Active Directory bevezetés kapcsán merült fel a Kedves Megrendelőben, 
hogy ő bizony egyszerre két azonos nevű munkaállomást szeretne csatlakoztatni a tarto- 
mányba. Tudjuk, hogy ez nem megy. Ha annak is utánajárunk, hogy pontosan miért nem 
közelebb kerülünk a meghatalmazotti kapcsolatok lényegéhez, s kiderülhet, a Professional 
változatok nem is túl sokban különböznek a Serverektől. Izgalmas utunkon Secure 
Channeleken bújuk át, SAM-ban kotorászunk, no és persze hiszünk (trust). 


RIS 


(IV. rész) 


A RIS kétféle telepítőkészlettel képes dolgozni. Az egyik a Riprep segítségével készített, a 
másik a CD-ROM, vagy Script alapú telepítőkészlet. A Microsoft RIS-sel csupán a Windows 
XP/2000 Professional telepítését támogatja, sem korábbi operációs rendszerek, sem a Windows 
2000 Server telepítését nem, azonban egy kis trükkel Windows 2000 Servert meg tudjuk etetni a 
risetuppal, így CD-ROM alapú telepítőkészletet tudunk készíteni a kiszolgálókhoz is. 
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Internettörvén 


vagy az elektronikus kereskedelem szabályozása? 
A 2001. év karácsonyán az információs társadalom tagjai is megkapták a maguk ajándékát a 
törvényhozástól - az Internettörvényt (2001. évi CVIII. törvény). Kérdés, hogy valóban Internettörvény 
született-e, azaz a jogalkotó ténylegesen kiterjesztette-e a jogi szabályozás hatósugarát a háló valamennyi 
jelenségére, vagy csupán az elektronikus 
kereskedelem, a gazdasági kapcsolatok körén belül maradt. 
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ASP Suli 


Wap alapok 

Előző számunkban bemutattuk a WML nyelv alapjait. Megtudtuk, hogy a wapos 
szolgáltatások kiszolgáló oldalról gyakorlatilag alig különböznek a hagyományos 
webes szolgáltatásoktól - ilyen alapon néhány apró beállítás után akár az Internet 
Information Services is képes wapos kiszolgálóként üzemelni. Akkor pedig már annak 
sincs akadálya, hogy a WML oldalakat dinamikusan, az ASP segítségével állítsuk elő! 








.NET Akadémia 


(II. rész) - .NET alaptípusok 
Az előző részben áttekintettük a .NET alapjait madártávlatból, valamint láttuk hogyan kell 
mezőket, metódusokat és jellemzőket definiálni egy osztályban. Ebben a részben megnézzük az 
osztályok további jellemzőit, körbejárjuk, hogy miért nagyon fontos az érték és referencia típusok 
megkülönböztetése. Menet közben érintjük a .NET egyik igen fontos sajátosságát, 
a nemdeterminisztikus objektum-életciklust is. 


XMLgessünk 


Az xml nagyszerű eszköz adatok átvitelére, heterogén rendszerek közötti információcserére, de csapnivaló adattárolásra. Redun- 
dáns és csak lassan lehet belőle kihámozni a tényleges információtartalmat. Hatékony adattárolásra már régóta léteznek megfele- 
lő eszközök, az adatbázisok. A legtöbb adatbázis azonban relációs elvekre épült, téglalap alakú információhalmazokban gondolko- 
dik, amelyek között kapcsolatok vannak definiálva. Hogyan valósítható meg az átjárás két világ között, 

a lehető leghatékonyabb módon? Erre keresem a választ a .NET eszközeivel. 
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CZ EZT 
Zárolás, livelock, deadlock S5sezssee 
Az SOL Server zárairól lapunk 2001 márciusi számában már olvashattak Soczó Zsolt tollából Zgrssstsa sees feet Za 
(28. oldal, Transact SOL VI. rész). Végigvette a zárak típusait, a tranzakcióizolációs szinteket, "él sáttásáái íg £ e 
majd a cikk végén könnyelműen megígérte, hogy legközelebb a deadlock következik. 5 beta árulom Ser ia 


Még egy év sem telt el, s íme a folytatás. 1 méj sz arzásit 
pl Cmotnásty 90 


Process Info 
a éjílads [procesz 0] 
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MsDownload 


- itt a végleges .NET Framework! 

2001 október közepétől a Netacademia Kft üzemelteti Magyarország egyik legnagyobb letöltőközpont- 
ját. A Microsoft Magyarország megbízásából elkészült oldalak az eddig megszokott tartalommal, de el- 
térő formában jelentkeznek. Az innen letölthető programok közül csemegézünk ebben a rovatban. 


Dupla KV 


RAID, Windows XP 


PT 





Rendezvénynaptár 


2002 tavaszán is folytatódik a TechNet Szemináriumok sorozata. A Microsoft Magyarország rendszermérnökei és vendégeik az előadások 
során áttekintik a kereskedelmi webhelyek biztonságát növelő technológiákat; kitérnek arra, hogy a Windows platform milyen eszkö- 
zökkel segíti a vállalati webes alkalmazások fejlesztését; betekintést adnak az SOL adatbázisok adminisztrációjába, valamint ismertetik 
a hamarosan megjelenő Windows .NET Server és Project 2002 újdonságait. Mindezt természetesen a jól ismert , 10090 technológia, 099 


marketing" szabály betartásával teszik. 


Nomádáélet a XXI. században: mobil IP 


Az emberi szabadságvágy egyik ősidők óta jelenlevő megnyilvánulási formája a helyváltoztatás, illetve a cselek- 
vés minőségét (kényelem, sebesség stb.) is figyelembevevő mobilitás. Amit a honfoglaló őseinknek a lovak és sze- 
kerek jelentettek, azt a XX. század embere számára az autó, a vonat, a repülő testesítette meg. Az utazás ma már 
az egyszerű halandók mindennapi életének is részévé vált. 
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Farkasokkal táncoló 


tulajdonképpen 
nem más, mint egy 
létező könyvtár 


Farkasokkal 
táncoló (IV. rész) 


Jobbról is, balról is körbejártuk már a fürtszolgáltatást, szinte minden 
beállítást ismerünk, csak még erőforrásokat nem hoztunk létre egy szálat sem. 
Ezt a fejezetet kizárólag e témának szenteljük. 


Az erőforrásokról általában 

Minden erőforrás létrehozásának hasonló a menete: az első pa- 
nelen megadjuk a nevét, a leírását, a csoportot, amelyhez tar- 
tozni fog, és az erőforrás típusát. Igazából ez a legbonyolultabb 
panel a művelet során. 

A következő lépés, hogy megadjuk, milyen állomások láthatják 
vendégül az erőforrást (preferred owner). A beállításokat a cso- 
portjától örökli, jobb meghagyni a felajánlott állapotot. Ezután 
a függőségek következnek, erről a témáról az előző cikkben bő- 
ven volt szó. Az utolsó panel erőforrásról erőforrásra változik, itt 
kell ugyanis az egyes típusok speciális, csak rájuk jellemző ada- 
tait megadni. Van azonban olyan erőforrás, ahol nincs is ilyen 
panel, mert egyszerűen nem kell megadni speciális beállítást. 

A legördülő listából összesen 15 erőforrástípus közül lehet válasz- 
tani, ám ez csalóka szám. A mappa megosztásból van mindjárt 
három altípus, de csak egy szerepel a listában. Van azután ún. 
általános szolgáltatás", meg , általános alkalmazás", amely nem 
más, mint olyan szervizek clus- 
teresítése, amelyek fejlesztésekor 
még nem gondoltak erre a fontos 
technológiára. Ezekből annyi le- 
het, mint égen a csillag. Szóval a 
15 senkit ne tévesszen meg. A kö- 
vetkezőkben minden erőforrástí- 
pusra szánunk néhány mondatot, 
a fontosabbakat pedig részlete- 
sebben is megvizsgáljuk. 


A létrehozás 


kacifántos 
megosztása. 


A fizikai lemez (physical disk) erőforrás 

Nagyon fontos, de nagyon egyszerűen létrehozható erőforrás. A 
varázsló utolsó lapján csak annyi dolgunk van, hogy megadjuk 
a lemezmeghajtó betűjelét, pontosabban kiválasztjuk a lehetsé- 
ges betűjelet. A nem közös és a már korábban kiválasztott, ilyen 
erőforrásként megadott lemezek nincsenek a listában. Az is elő- 
fordulhat, hogy egy általunk odagondolt lemez nem jelenik 
meg. Ekkor meg kell győződni arról, hogy: 

Mindkét állomás azonos betűjelet adott-e a lemeznek? 

A lemezen van-e egyedi jel (disk signature)? 

Az egyedi jel létéről mindkét állomás biztosan tud-e? 

A diszk nem dinamikus-e véletlenül? 

Minden gyártóspecifikus eszközmeghajtót telepítettünk? 

Az első feltételt könnyű ellenőrizni a lemezkezelővel. A második 
feltétel automatikusan teljesül, ha legalább egyszer elindítottuk 
a lemezkezelőt az erőforrás létrehozása előtt, és hagytuk, hogy a 
felbukkanó varázsló rátegye a , disk signature"-t az új lemezekre. 


WB UND E 


vorkinú vithn 


windows / 


Ugyanez a varázsló ebben a körben dinamikus lemezekké konver- 
tálná a diszkeket, de ezt ne engedjük! A cluster lemezkezelője (a 
clusdisk eszközmeghajtó) csak egyszerű (basic) lemezeket kezel. 
Az utolsó feltételt saját tapasztalataim alapján magam találtam 
ki. A lemezek - ahogy erről korábban már volt szó - valójában 
nem igazi lemezek, hanem valamilyen lemeztömb logikai felosz- 
tásai. Ez a lemeztömb, különösen ha diszkalrendszerről van szó, 
számos gyártóspecifikus eszközmeghajtót is igényelhet, ame- 
lyek telepítése nem triviális. Alapszabály tehát, hogy a fizikai 
lemezerőforrások létrehozása előtt győződjünk meg arról, hogy 
a fürt alatt dohogó lemezrendszer jól működik-e, és semmilyen 
megmagyarázhatatlan , tulajdonsága" sincs. Olyan ez, mint a 
házépítés: csak jó alapokon épül jó otthon. 


Az IP cím (IP address) erőforrás 

A lemezekhez hasonlóan szintén nagyon egyszerű és nagyon fon- 
tos erőforrás. A létrehozásához csak egy pontos címre és egy alhá- 
lózati maszkra van szükség. A virtuális gép minden egyéb TCP/IP 
beállítását az őt futtató állomástól veszi - egyszerűbb így az élet. 
Gyakori hiba, hogy az alhálózati maszkot rosszul adja meg a rend- 
szergazda - a hatása éppen az, mint egy normál szerver esetén. 


A hálózati név (network name) erőforrás 

A hálózati név nem kevésbé fontos erőforrás, mint az előző kettő 
volt. Ez teszi lehetővé, hogy a virtuális szerverre név szerint hivat- 
kozhassunk. A név - sajnos - NetBIOS név. A Windows 2000 ugyan 
regisztrálja a WINS mellett a DNS Servernél is, ám ez sovány vigasz. 
Az igazság a 0235529 cikkben van: a Windows 2000 cluster szol- 
gáltatása és a NetBIOS egyelőre elválaszthatatlanok egymástól. 


A közös mappa (file sharing) erőforrás 

Az első három erőforrás ahhoz szükséges, hogy egy virtuális ki- 
szolgáló egyáltalán létrejöhessen. A közös mappa viszont már 
gazi" szolgáltatás. Három alfaja is van. 

A létrehozás tulajdonképpen nem más, mint egy létező könyv- 
tár kacifántos megosztása. Ez annyiból áll, hogy a könyvtárnak 
már léteznie kell, a megosztás pedig az erőforrás létrehozásával 
történik. Az eltávolítást épp fordítva kell elvégezni: előbb meg 
kell szüntetni az erőforrást (ezzel megszűnik a megosztás) , majd 
lehet törölni a mappát. Azért írom le ezt a triviálisnak tűnő lé- 
péssort, mert kezdetben számtalanszor magam is eltévesztettem, 
és előbb töröltem a könyvtárat, minthogy megszüntettem volna 
az erőforrást. A következménye az volt, hogy a virtuális szerver, 
vagyis az erőforrás-csoport ész nélkül elkezdett egyik állomásról 
a másikra vándorolni, hátha ezzel orvosolhatja a , hibás" állapot- 


808. 08. 


ba került erőforrását. Nem sikerült neki... A tanulság, hogy ki- 
szolgálófürt esetén meg kell tanulni: a megosztásokat a Cluster 
Administrator segítségével kell létrehozni és megszüntetni. 

A varázsló utolsó paneljén van egy , Advanced" jelzésű gomb, 
amellyel előcsalogatható a háromféle megosztás létrehozását 
lehetővé tévő ablak. Ez az: 


Advanced File Share Prope... 


C Normal share 
€ Disroot 
(7 Share subdírectories 
TT Hide subdirectory shares 


box 1 cm ] 


9 Fáljmegosztás típusok a fürtön 





A normális megosztás pontosan az, ami a neve. Ugyanilyen 
megosztást tud minden Windows 2000 termék, ez csupán a ren- 
delkezésre állásában jobb. Mivel semmi különbség nincs, a sza- 
bályok sem különböznek: javasolt a megosztás jogosultsági beál- 
lításait alapon hagyni, és NTFS jogosultságokkal szabályozni a 
felhasználók hozzáférését az állományokhoz. Egy fontos tudniva- 
ló azért van: a clusterszolgáltatás fiókjának legalább olvasási jo- 
gokkal kell rendelkeznie a közös mappán. Ha ez nincs így, akkor 
nem képes az erőforrást működőképes állapotba hozni. Ez persze 
nem a létrehozáskor jelent problémát, hanem amikor egy bizton- 
sági felülvizsgálat során megvonják tőle a jogokat. 

Az első változatnál érdekesebb a ,share subdirectories" típusú 
megosztás, különösen akkor, ha az alkönyvtárakat automatikusan 
elrejtjük. Mire is jó ez? A Windows NT 4.0 minden verziója küzd 
azzal a problémával, hogy csak megosztásokhoz képes csatlakoz- 
ni, megosztások alatti almappákhoz már nem. Ez pedig probléma 
a felhasználói könyvtáraknál, mert a szegény felhasználó elveszik 
a sok könyvtár között, és nem találja a sajátját. Szemfüles rend- 
szergazdák úgy segítettek magukon, hogy megosztották a fel- 
használók könyvtárait is, és hogy ne sorakozzon több száz 
megosztott mappa a tallózó szolgáltatásban, ezért a könyvtárak 
megosztási nevei kaptak egy $ jelet, vagyis rejtve maradtak. No, 
ez a szolgáltatás pont ezt a funkciót végzi, csak most már auto- 
matikusan. Az igazat megvallva kellett is ez. Korábban ugyanis az 
ilyen megosztásokat is erőforrásként lettünk volna kénytelenek 
definiálni, az eredeti fürtkiszolgáló szoftver verzió azonban csak 
900, a jelenlegi pedig csak 1600 erőforrást kezel, s bizony akadt 
olyan hely a világon, ahol ez korlátot jelentett. Arról nem is be- 
szélve, hogy ilyen sok erőforrás terhelte is a clustert rendesen, 
míg most a megosztott alkönyvtárak már nem erőforrások többé, 
így minden a helyére került. Minden? No, ha majd csak Windows 
2000, vagy XP munkaállomások lesznek a hálózaton, akkor lehet 
faragni a scriptet, amely megszünteti a rengeteg rejtett megosz- 
tást, és a normál almappához csatolja a felhasználókat. 

Egy lehetséges hibára szeretném felhívni még a figyelmet: ha a 
Windows NT-hez mellékelt , User Manager for Domains" eszköz- 
zel hozzuk létre a felhasználó könyvtárát, akkor annak jogosult- 
sági listájában egyedül a felhasználó lesz benn teljes eléréssel, 
és semmi-senki más. Ezért aztán a fürtkiszolgáló fióknak sem 
lesz elegendő joga a könyvtárat automatikusan megosztani. Ez 
éppen az n--1. ok, hogy ne NT-t használjunk. (Épp most vonja ki 
a piacról a Microsoft az NT4-et - a szerk.) 

Nem esett még szó a DFS-megosztásról. A betűszó annyit tesz, 
hogy elosztott fájlrendszer, és arra való, hogy a rendszergazdák 
egyetlen közös névtérbe rendezhessék a megosztásaikat, egyfaj- 
ta óriási virtuális megosztásrendszert létrehozva. A technikának 
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az az előnye, hogy a jól megszerkesztett névtér ál- 
landó maradhat, míg alatta a megosztások és ki- 
szolgálók tetszőlegesen mozoghatnak, változhat- 
nak. Ez a szolgáltatás már a Windows NT 4.0-ban is je- 
len volt, igaz, nem a CD-n, hanem webről letöltve lehetett 
telepíteni. A gyenge pont pedig az volt, hogy a DFS gyökere 
(amelyből csak egy lehetett) kártyavárként döntötte össze a 
névteret, ha nem volt elérhető - Achilles sarok volt tehát. 
Emiatt nem is vált igazán népszerűvé a DFS. 
A Windows 2000 azonban változtatott a helyzeten kétfélekép- 
pen is. Egyrészt megjelent a tartományalapú DFS-rendszer, 
amely a névteret az AD-ban tárolja, ami így már redundánssá 
vált. Másrészt megjelent a fürtszolgáltatásban a DFS megosztás 
létrehozása. Miért volt szükség erre, amikor ott az AD? Két ok 
miatt is. Egyrészt nem mindenki akar Active Directory szolgál- 
tatást, másrészt ehhez az AD-val integrált DFS-hez vagy Win- 
dows 2000-es ügyfelek kellenek, vagy AD klienst kell telepíteni 
minden egyes korábbi Windows verzióra. 

A fürtszolgáltatás rendelkezésre állása pont az Achilles sarkot 

szünteti meg, de kompatibilis a korábbi NT verziókkal is. Az 

ilyen DFS gyökérmegosztást , Stand alone" DFS-nek hívják, meg- 
különböztetve az AD-val integrálttól. Minden szépsége ellenére 
ennek a szolgáltatásnak is vannak korlátai, nevezetesen: 

5 Csak egyetlen DFS megosztást lehet létrehozni a teljes fürtön. 

-8 Nem lehet egyszerre AD-val integrált DFS-t és Stand alone DFS-t 
létrehozni a kiszolgálófürtön. 

Ez azt jelenti, hogy bizony a DFS megosztásnak helyet adó vir- 

tuális kiszolgáló neve jó időre beleég a rendszerünkbe. 

Van még két súlyos DFS korlát a fürtszolgáltatásnál. 

-8 Az AD-val integrált DFS létrehozásakor a gyökérkönytár nem le- 
het a fürt közös lemezein. 

"2 A fürt közös lemezein található megosztások, amelyek részei a 
DFS névtérnek, nem használhatják a Windows 2000 fájlrepliká- 
ciós szolgáltatását. 

Az első problémát még 

csak-csak át lehetne hi- 

dalni egy nem túl ele- 

gáns megoldással, de a 

második korlát bizony 

mellbevágó. Ez ugyanis 
azt jelenti, hogy a közös 

névtérbe szervezett, a 

vállalat eltérő telephe- 

lyein . eltérő — módon 
használt könyvtárrend- 
szert nem lehet automa- 
tikusan replikálni. (Pél- 


rendezhessék a 


óriási virtuális 


dául ugyanazon elérési meg osztásrendszert 
utat használva az egyik létr ehozva. 


telephelyen létrehoznák 

a termelési jelentést, az 

automatikusan átreplikálódna a központba, ahol a vezetőség a 
WAN vonalakat nem terhelve nézegethetné azokat.) Jelenleg csak 
az Exchange 2000 nyújthat megoldást a problémára saját mappái- 
nak replikációjával. No és a .Net Server, ha megjelenik. . . 

A fürtkiszolgáló fizikai lemezeinek és közös mappáinak érdekes 
problémája a hibajavítás, de erről nem itt, hanem egy másik 
cikk keretében szeretnék írni. A hasznos olvasnivalókat a cikk 
végén soroltam fel. 


A nyomtatási sorkezelő (print spooler) erőforrás 


A közös mappáknál nem kevésbé érdekes a közös nyomtatók lét- 
rehozásának feladata. Az alapvető tudnivalók: 
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A DFS betűszó annyit 
tesz, hogy elosztott 
fájlrendszer, és arra való, 
hogy a rendszergazdák 
egyetlen közös névtérbe 


megosztásaikat, egyfajta 
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úg" A nyomtatási sorkezelő csupán alapja a fürtszolgálta- 


Me 


tás hálózati nyomtató megosztásának. Létrehozásával 
azt tesszük lehetővé, hogy lehessen megosztott, nagy 
rendelkezésre állású nyomtatónk. 

Egy virtuális gépen csak egy spooler erőforrást hozhatunk 
létre, de az akármennyi hálózati nyomtatót is kiszolgálhat. A 
nyomtató csak akkor lehet közös, ha hálózatról (értsd: TCP/IP 
alapon) el lehet érni, és nem csatlakozhat párhuzamos porton 
az egyik vagy.a másik állomáshoz. 
A hálózati nyomtatónak szüksége van a TCP/IP nyomtatási szol- 
gáltatásra (esetleg a UNIX vagy más nyomtatási szolgáltatásra 
környezettől függően), ezeket tehát telepíteni kell az erőforrás 
létrehozása előtt mindkét kiszolgálóra. Végezetül hozzunk létre 
a kiszemelt virtuális gépünk egyik fizikai lemezén egy ,Spool" 
könyvtárat. A továbbiakban feltételezzük, hogy van már egy vir- 
tuális szerverünk névvel, IP-címmel és egy fizikai lemezzel. 
Jöhet az erőforrás: az első lapon válasszuk ki a , Print Spooler" erő- 
forrástípust, és adjunk nevet neki. A következő lapon hagyjuk vál- 
tozatlanul a lehetséges állomásokat. A függőségek paneljén te- 
gyük függővé a sorkezelőnket a hálózati névtől és a fizikai lemez- 
től, végezetül az utolsó lapon adjuk meg a korábban létrehozott 
Spool könyvtárat, ahol a nyomtatószerver az átmeneti állományait 
tárolhatja. Ezzel kész a sorkezelő, de még csak az út felénél járunk. 
Nincs ugyanis még sem portunk, ahová az adatot küldenénk, sem 
meghajtónk, sem közös nyomtatónk. De most lesz! 
Tallózzunk a hálózaton az egyik fürtállomásunkhoz. Lépjünk be 
a nyomtatók mappába. Válasszuk ki a , Fájl" menü , Server 
Properties" menüpontját. 


HP Laserdet 1100 (MS) 
HP Laserdet 5P inté 
HP Laserdet 5P 
ho phototmart 1218 se. 
ho photosmart 121856. 
Konics IP-421 PostScript. intel 
Konica IP-421 PostScript. intel f 
Xerox DocuPrint N24/... intel Windows NT 4.0 or. 2000 
Xerox DocuPánt N32 PS intel Windows 2000 or XP 

2 DD IATA letal 
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5 Nyomtatómeghajtók az egyik állomáson 


A Driver fülön adjuk hozzá a leendő nyomtatónk meghajtóit. 
Amint az a képen is látható, többféle nyomtató eszközvezérlő 
létezik, ha tehát többféle kliensünk van, mindegyik rendszer 
meghajtóját hozzá kell adnunk. Ez némely Windows NT 4-es 
meghajtónál gondot okozhat, ezért egy másik gépen érdemes 
kísérletezgetni a nyomtatók meghajtóival. Ha valaki végképp 
nem boldogul, ajánlom figyelmébe a Fixprnsv.exe segédprogra- 
mot és a 0247196 cikket. Mivel a téma nem igazán clusterspe- 
cifikus, ezért az ennél a fázisnál felmerülő problémákat most 
nem tudjuk felsorolni és megoldani. 

Ha megvannak a meghajtók az első node-on, akkor ugyanezt a mű- 
veletet el kell végezni a másik állomáson is. Azért kell ezt megtenni, 
mert a nyomtatómeghajtók nem a közös lemezterületen találhatók, 
hanem az állomások print$ megosztásaiban. Figyelem! A meghajtók, 
és később a frissítéseik is legyenek azonosak a két állomáson, külön- 
ben megjósolhatatlan furcsaságokba ütközhetünk a későbbiekben. 
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Az eszközkezelők után jöhetnek a közös nyomtatók. Tallózzunk ezút- 
tal a virtuális szerverünkhöz. Látható, hogy a megosztások között 
létrejött egy , Nyomtatók" speciális mappa, amelybe belépve ponto- 
san ugyanazokat a feladatokat végezhetjük el, mint egy hétköznapi 
Windows 2000 nyomtatószerveren. Nosza, adjuk hozzá azt a nyom- 
tatót! Amikor a varázsló a port kiválasztásához ér, adjunk meg nyu- 
godtan új portot, válasszuk a ,Standard TCP/IP"-t, vagy azt, amelyik 
a mi környezetünkben a 
megfelelő. Adjunk 
egyedi nevet a portnak. 
Visszajutunk az előző 
ablakhoz, válasszuk ki 
az újonnan létrehozott 
kaput, és lépjünk to- 


A meghajtók, és 
később a frissítéseik 
is legyenek azonosak 

a két állomáson, 


vább. A Windows 2000 különben 
alatt kicsit könnyebba —— megjósolhatatlan 
helyzetünk, mert a port furcsaságokba 


létrehozását csak egy- 


szer kell elvégezni, a ütközhetünk a 
konfigurációs adatokat 


1 K későbbiekben. 
ugyanis a cluster hive 


alatt tárolja a fürt, tehát közös részen. A korábbi verzióknál ez még 
nem így volt, ott előbb helyi nyomtatókat kellett létrehozni mindkét 
állomáson, hogy létrejöjjenek a portok. No, ez már a múlté. 

A meghajtók között válasszuk ki a már egyszer megadottat, így 
a következő panelen lehetőségünk lesz megtartani az előzete- 
sen feltett drivereket. Ezután már csak nevet kell adnunk a 
nyomtatónak, és rendelkeznünk kell, hogy a rendszer ossza meg 
a felhasználók felé. Ha van AD címtárunk, akkor publikálhatjuk 
a nyomtatót a címtárba is. Ezzel el is készültünk. A biztonság 
kedvéért javaslom, hogy teszteljük a létrehozott nyomtatót, 
majd mozgassuk át a másik állomásra a virtuális szervert, és vé- 
gezzük el újra a tesztet. Így lehetünk csak biztosak, hogy mű- 
ködik az átkapcsolás. Azt is ellenőrizzük le, hogy minden klien- 
sünk képes nyomtatni, valamint, hogy a Windows 2000 és Win- 
dows XP ügyfelek látják az Active Directoryban a nyomtatónkat. 
Ezzel megteremtettük a megbízható, központosított nyomtatás 
alapjait. 


Végezetül néhány Knowledge Base cikket sorolok fel, amelyek 
eligazítást nyújthatnak a cikk által érintett problémák esetén. 
0185212  Cluster Server Does Not Support More Than 

900 Shares 

Securing a Common Folder 

SP4 Cluster Shares Must Be Reset to Recognize 
Added Subdirectories 

Folder Share-Level Permissions Override Subfolder 
Permissions 

How to Create File Shares on a Cluster 

Security Considerations When Implementing 
Clustered File Shares 


0186496 
0194831 


0208243 


0224967 
0254219 


0257389 Microsoft Cluster Server Does Not Share Folders 
Automatically 

0229733 — During Cluster Failover Print Oueue Monitoring 
May Stop 


Lepenye Tamás (MCSE 2000) 
lepenyet omal.hu 
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Egy Windows 2000 Active Directory bevezetés kapcsán merült fel a Kedves 
Megrendelőben, hogy ő bizony egyszerre két azonos nevű munkaállomást szeretne 
csatlakoztatni a tartományba. Tudjuk, hogy ez nem megy. Ha annak is 
utánajárunk, hogy pontosan miért nem, közelebb kerülünk a 

meghatalmazotti kapcsolatok lényegéhez, s kiderülhet, a Professional változatok 
nem is túl sokban különböznek a Serverektől. Izgalmas utunkon Secure 
Channeleken bújuk át, SAM-ban kotorászunk, no és persze hiszünk (trust). 


A tartományhoz csatlakozás menete 

Először tekintsük át a sokak által naponta végrehajtott folyama- 

tot. A csatlakozás kétféleképpen végezhető el: 

"0 vagy mindent a munkaállomás oldaláról hajtunk végre (és meg 
kell adnunk egy tartományi erős ember nevét és jelszavát) 

- vagy a munka oroszlánrészét rábízzuk egy megfelelő jogosult- 
ságú tartományi felhasználóra 

A csatlakozáskor létrejön egy nagyon fontos objektum a címtár- 

ban (nem a munkaállomáson!): a számítógépfiók, más néven 

Computer Account Object (CAO. Ennek létrehozásához kell egyéb- 

ként megadnunk egy erős ember nevét és jelszavát). 

Ha mindent a munkaállomás oldaláról hajtunk végre, a CAO lét- 

rejön, és azonnal felhasználódik, a folyamat a háttérben, csend- 

ben lezajlik. Ha a másik utat járjuk, választ kaphatunk arra, 

hogy miért nem ,lóghat" két azonos nevű munkaállomás egy 

tartományon. Hozzuk létre a CAO-t a tartományban: 


CETETEZETTTS ETT 2 
Createin: — falatrax.hu/ 
(EZI 





Computer name: 4 
Masina 
Computer name (pre:windows 2000)- 


MASINA 


The following user or group can join this computer to a domain, 
User or group: 


fPefautt Domain Admins 
TT Allow pre:wWindows 2000 computers to use this account 
OK I Cancel I 
0 Computer Account Object létrehozása Windows 2000 tar- 


tományvezérlőn. Feltétlenül adjuk meg, hogy ki lesz képes 
felhasználni! (Change gomb) 





Mint látható, itt a MASINA nevű masina számára készítjük elő a 
terepet. Nyilvánvaló, hogy ezen a ponton még nem dőlt el, hogy 
pontosan melyik gép lesz az az egyetlenegy, amelyik a későb- 
biekben használni fogja. Ha van két, egyformán MASINA nevet 
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viselő munkaállomásunk, most még mindkettő rávetődhet - de 
csak az egyik, a ,gyorsabbik" győzhet. Vajon miért? 


A Windows NT/2000 tudathasadása 

Egy Windows 2000 valójában két személyiség nevében ténykedik 
a hálózaton. Egyfelől itt van a bejelentkezett felhasználó, Júzer 
Jolán, akinek van ugyan egy-két joga és feladata, de ő csak ven- 
dég a gépen. Sokkal jobban a géphez van nőve a saját tudatál- 
lapota. Akár be van személyesen jelentkezve valaki, akár nincs, 
az NT/2000 önmaga is tesz-vesz a hálózaton. Képzeljük el így: 


Na 


User mód: 
Júzer Jolán 


Tee] 
Kernel mód: ej 
MASINA$ ei 


60 A Windows 2000 személyiségei. Ha nincs bejelentkezve 
hús-vér ember, a gép akkor is VALAKI! 


Az ábra enyhén csúsztat annyiban, hogy nem a teljes operációs 
rendszer fut kernel módban, sőt, jobbára csak az eszközmeghajtók, 
és az oprendszer lelke (Hardware Abstraction Layer) , de mivel most 
éppen a gép lelkéről beszélünk, ennyi tárgyi tévedés még , belefér". 
Miután megállapítottuk a két személyiséget, megvizsgálhatjuk, 
hogy hogyan jelennek meg a hálózaton. Júzer Jolán attól az aki, 
hogy helyesen megadta nevét és jelszavát. Nem meglepő ezek 
után, hogy MASINA is azért az, aki, mert bootoláskor megadja 
nevét és jelszavát a tartományvezérlőnek. Ez ugyanis a háló- 
zati azonosítás alapja, akár gép az ,illető", akár ember. 

A gép bejelentkezési neve nyilván a gép nevéből származik (egé- 
szen pontosan egy dollárjel hozzábiggyesztésével). Ha belekuk- 
kantunk az Active Directoryba a telepítőlemezen található 
Support Tools eszközkészlet LDP.EXE eszközével (pontos haszná- 
latáról a tavaly májusi számban olvashattak) , ezt láthatjuk: 
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Minden NT alapú, 
tartományi tag 
operációs rendszer 
már a rendszertöltés 


bejelentkezik a 








DCshu 1 objectCategory: e 
in DC-falatrax DC-hu N-Computer,CN-Schema,CN-Configuration, DC 
-c iatrae DC-hu; 
; 5) objectClass: top; person; 
—CN-ForeignsecurityPrincipals DC-falatrax! TE user; computer; 
CN-infrastructure DCsfalatrax, DC-hu 2 objectGUID: 
FCNzLostándFound DC-falatrax DC-hu TO9c37a1ÍBFddbe§743-5cbZabá7da5t: 
E-OU- marketing DC-falatrax DC-hu 1 objeciSid: 
1 CNzajOUzmarketing DCsfalatrax DC5 ÍS-15-47AF2515-5274C742-500CEBDB-45 4; 
153 primaryGrouplD: 515; 
1 pwdlastSet: 126508905450329728; 
: masina; 


— CNZANDROMEDA-AGFA-AccuSet v52.3 

CN-bOU marketing DC-falatrax DC 
—eNzc OU zmarketing DC-falatrax DC 

CN-Joe Lockout, OUzmarketing DC--fal 
€ HEZEZEKTETETEETTIZTEETET 

No children 

— CNantámasina OU marketing DCs-falat 
CNaSystem DCsfalatrax DCshu 
CNelsers DCfalatrax DCshu 
CN-Configuration DCsfalatrax DC-hu 





1 usSNCreated: 6050; 
15 whenChanged: 1271/2001 20:23:0 
entral Europe Standard Time Central Europe 
aj [Davtight Time; E] 
Ready EGET Gá 








5 A sAMAccountName a számítógépfiók bejelentkezési neve. 
Ha a jelszavára is kíváncsiak vagyunk... 


A neve tehát megvan. De mi lehet a jelszava? Nyilván van jel- 
szava, mert ha nem lenne, már régesrég ettől a biztonsági rés- 
től lenne hangos az Internet. És az emberekhez hasonlóan egy- 
valaki tudja csupán ez a jelszót: maga a gép! Csatlakozás köz- 
ben a MASINA$ nevű illető csöndben megváltoztatja az (akkor 
már saját) jelszavát valami random jelsorozatra. És ezzel a lé- 
péssel záródik be az a kiskapu, amin át újabb, azonos nevű gép 
juthatna a tartományba. Ha jön egy újabb MASINA nevű számí- 
tógép, akkor az - a helyes jelszó ismerete híján - üres jelszóval 
próbálna csatlakozni, ami már nem megy! 

Esetleg bújkál bennünk a kérdés, hogy vajon a munkaállomás 
hol is tárolja a saját jelszavát. Júzer Jolánról tudjuk hol tárolja: 
vagy a buksijában, vagy kiragasztja a monitorra. És a MASINA? 
ő bizony a regisztrációs adatbázisban dugdossa előlünk, itt: 


HKLM/SECURITY/Policy/Secrets/$MACHINE.ACC 


Egy REG NONE (!) típusú változóban. Ja, hogy ehhez nem fé- 
rünk hozzá? De hát mondtam, hogy dugdossa! :) 


A Secure Channel 

Minden NT alapú, tartományi tag operációs rendszer már a rend- 
szertöltés folyamán bejelentkezik a tartományba. A bejelentke- 
zés után ez a kapcsolat egészen az 
operációs rendszer leállításáig 
megmarad. Mintha a gép egy kiska- 
put nyitna magának a tartomány 
felé, hogy a későbbiekben, amikor 
majd mindenféle Júzer Jolánok hi- 
telesítését, és egyéb feladatokat 
kell elvégezni, szabadon ki-be sé- 
tálhasson rajta. A kiskapu hivatalos 
neve biztonságos csatorna, azaz 
Secure Channel. Történelmi tény, 
hogy a Windows NT 4.0 a Service Pack 4 javítócsomag megjelenéséig 
nem volt képes titkosítani a Secure Channel forgalmát: minden adat, 
mely azon jött-ment (Access Tokenek stb.), olvasható formában ke- 
rült ki a kábelre. 


folyamán 


tartományba. 


Kitérő: mivel a Windows 9x ágnál nincs számítógépfiók, 
nincs Secure Channel sem. A mai napig titkosítatlanul 
áramlik - a jelszón kívül - minden hitelesítési adat ezekre 
a gépekre. Vállalati hálózaton nincs helyük! 


SP4 előtt a Secure Channel biztonsága annyiban merült ki, hogy 
erősen bíztunk benne: a gép indulásakor létrejött TCP csatorna 
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két végpontját senki sem képes elmozdítani, és magára irányí- 
tani. Mivel azonban a neten sorra jelennek meg a gonoszabbnál 
gonoszabb toolkitek, nem meglepő, hogy a mai operációs rend- 
szereken némiképp magasabbra került a léc: 

2 a csatorna forgalma valóban titkosított 

-€ a végpontok eltéríthetetlenségéről digitális aláírással gondos- 

kod(hat)unk 

Az alábbi ábrán egy megkímélt állapotban lévő, soha agyon nem me- 
nedzselt tartomány alapértelmezett biztonsági beállításait láthatjuk, 
mely szerint - ha a túloldali gép ezt lehetővé teszi (when possible) — 
titkosít ÉS aláír minden adatot, ami a csatornában folyik. 
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jEdjseawre channek Digtally encrybt or 5gn secure channel data (ahvavs) 


Jöecure channet: Digtally encrypt secure channel data (uhen possble) 
Secure charnet Digtaly ugy secure channel data (nhen poszt) 
szára sizong (vino 2009 or lter) seseen hag 
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5 Egy tartományvezérlő alapértelmezett Secure Channel be- 
állításai. Ha lehetséges (when possible), a csatorna adatai 
titkosított és aláírt formában közlekednek 


Erősíteni oly módon lehetne a biztonságon, hogy kötelezővé 
tesszük mind a digitális aláírást, mind a titkosítást - és elbú- 
csúzunk szeretett Windows 9x-einktől (legfelső sor a keretben), 
További érdekes lehetőség a Windows NT 4.0 lerúgása, mely a 
keret legalsó opciójával érhető el: strong kulcs - NT4 kizárás! 
Már a kereten kívülre szorult, csak megemlítem: a Windows 2000 
alapértelmezésben nem engedélyez clear text (ilyenkor titkosí- 
tatlan még a jelszó is) bejelentkezést, így SaMBa kiszolgálóin- 
kon lehet, hogy frissíteni kell egyet - vagy az itt látható opciót 
engedélyezni, bár én ezt nem tenném. 


Mire lehet jó még a Secure Channel? 

Amikor a felhasználó erőforrást keres a hálózaton, jobbára a 
Network Neighborhoodon kattintgat szegény. Sokszor hiába te- 
szi, mert a jó öreg Browse szolgáltatás hajlamos percek óta be- 
kapcsolt gépeket nem mutatni, míg félórája kinyomott gépeket 
minden további nélkül felkínál. Hogy miért? Az egy olyan cikk 
témája lenne, amit nem érdemes megírni. A Browse szolgáltatás 
elavult. Nagyvállalati, több IP alhálózattal tarkított környezet- 
ben ennyit tud és kész. Ezt kapja a júzer, 

De mi jár a rendszergazdának? A Windows NT 4.0 - féle Server 
Manager csodálatosan megmutatja, mely gépek vannak egy adott 
pillanatban bekapcsolva. Úgy sorolja fel kicsi okos ablakában az 
összes gépet, hogy kék színnel jelöli a bekapcsoltakat, és szür- 
kével a halottakat. Honnan tudja mindezt? Hát onnan, hogy ami- 
hez aktuálisan van Secure Channel, az nyilván fut. Amihez meg 
nincsen, hát az bizony ki van kapcsolva. Most jön a svédcsavar! 
A Windows 2000-ben hála Istennek végre megszabadulhatunk 
az amúgy is működésképtelen Browse áldatlan és haszontalan 
szolgáltatásaitól, mert a My Network Places felkínálja nekünk a 
címtár böngészését is. 


0 A My Network Places 
elágazik! A Microsoft Win- 
dows Network a jó öreg, és 
megbízhatatlan Browse, míg 
a könyvecske a címtár kuta- 
tását teszi lehetővé 





tUúüd. BUZ. 


Már csak egy lépésnyire vagyunk a Server Manager által mutatott 
valós képtől. Hagyjuk a csudába a Microsoft Windows Networköt, és 
menjünk bele a Directoryba! Csodálatos, hierarchikus világ tárul 
majd a szemünk elé, melyben ott lesznek a cég szervezeti egysé- 
gei, felhasználói, nyomtatói és számítógépei. S ha egy csöpp sze- 
rencsénk van, a kikapcsolt számítógépek szürkék, míg a bekapcsol- 
tak kékek lesznek, mint annak idején az NT4 Server Managerében... 
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0 Figyeljük meg az Explorer által mutatott címet! Az 
NTDS;// (NT Directory Services) arra utal, hogy a címtárban, 
az Active Directoryban kutakodunk. Én, Júzer Jolán, hozzáfé- 
rek a címtárhoz! 


Megérkeztünk a címtárba. Látunk két kék gépet: az egyik a már 
jól ismert MASINA, a másik pedig az NTAMASINA nevet viseli. Ha 
kék, akkor fut nemde? Sajnos nem. Az Active Directory sok nél- 
külözhetetlen szolgáltatást hozott ugyan az NT4-hez képest, de 
most rábukkantunk egyre, amit elveszített. Nem tudja megmu- 
tatni, hogy egy géphez van-e Secure Channel, azaz fut-e. :-( 

Mindig minden gép ikonja kék. 

Ennek a sajnálatos malfunkciónak legalább két oka van. 

1. Az Active Directoryt nem arra találták ki, hogy illékony adato- 
kat tároljunk benne. Egy munkaállomás állapotinformációja 
sajnos túl dinamikus adat ahhoz, hogy értelme legyen be- 
tenni a címtárba. Többszáz gépes hálózaton óriási, és job- 
bára felesleges replikációs forgalmat generálna. Ezen a Win- 
dows .NET Server fog segíteni, ahol különleges és ravasz 
replikációs lehetőségek jelennek meg a címtárban. 

2. Holis van a Secure Channel vége? Ha van öt tartományvezér- 
lőm, akkor... 


Hol az alagút vége? 

A Secure Channel fizikai valójában nem más, mint egy TCP csa- 
torna, mely , örök időkig" fennáll. Ha van mondjuk öt tartomány- 
vezérlőm, vajon hogy alakul a csatorna? Mivel TCP csatornáról van 
szó, nyilvánvaló, hogy maximum két végpontja lehet. , Kirojtoso- 
dott", háromvégű TCP csatorna nincs, és nem is lehet (a TCP szek- 
venciaszámok miatt). Emiatt nem meglepő, hogy a Secure 
Channel a munkaállomás és valamelyik DC között húzódik. Egyet- 
lenegy DC áll a túlvégen. Arra a kérdésre nehezen tudnánk kapás- 
ból válaszolni, hogy az öt közül pontosan melyik az, de egy tám- 
pontunk lehet: a Windows 2000 munkaállomások hozzájuk közel 
eső, saját telephelyükön lévő DC-t keresnek, és - ha csak lehet - 
ahhoz csatlakoznak bootoláskor. Az NT4-ről ez korántsem mond- 
ható el. Ha nem bűvészkedünk Resource Kit bigyókkal, akkor az 
NT4 a leghamarabb válaszoló DC-vel lép nászra, jöjjön a válasz 
akár a földgolyó túloldaláról. 

Ha feltelepítjük a Windows 2000 CD kincseit a SupportYTools könyv- 
tárból, lesz egy NlTest.EXE-nk, amivel a Secure Channel kezelése is 
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megoldható. Nem mintha állandóan babrálni kellene, 
de ha valakit érdekel, sok egyéb hasznos funkció mel- 
lett az NlTest ezt nyújtja a Secure Channel kezeléséhez: 


Funkció (munkaállomásról 
futtatva!) 

/SC OUERY:cDomain Kiírja a Secure Channel adatait. 
Namez 

/SC RESET:-cDomain 
Namez[-DcName:] 


Kapcsoló 





Kikényszeríti a Secure Channel menet köz- 
beni lebontását és újraépítését. Így le- 
het visszairányítani a csatornát, ha vélet- 
lenül távoli DC-hez került 

A Computer Account jelszavának 
átállítása. 





/SC CHANGE PWD:c 
DomainNamez 


A Secure Channel valódi szerepe 

Sokat beszéltünk a Secure Channelről, éppen csak az értelme 
hiányzik még. Ha csak Júzer Jolán bejelentkeztetéséhez lenne 
rá szükség, akkor nem lenne rá szükség, Jolika bejelentkezhetne 
önmaga, anélkül, hogy (őelőtte jóval) a gép bejelentkezne. Így 
dolgozik a Windows 9x, és nem dől össze a világ. 

A biztonságos csatorna valójában nem a titkosítás miatt kell (lát- 
tuk, az NT4 még nem sokat bíbelődött a csatorna titkosításával) , 
hanem amiatt, hogy a központi címtár pontosan tudja a , vonal" 
túlsó végén lévő ,egyed" azonosságát. Erre azért van szükség, 
mert a gép - függetlenül attól, hogy Jolán dolgozik-e rajta - 
megosztásokat publikál(hat) a hálózaton, és ennek kapcsán idő- 
ről időre tartománylekérdezéseket kell végeznie, hogy megállapít- 
hassa, vajon a csatla- 
kozni  szándákozónak 
megvan-e ehhez a szük- 
séges jogosultsága. 

Az alábbi ábrán egy ki- 
csit nagy a nyüzsgés, de 
remélem jól szemlélteti, 
ahogy a MASINA (szinte) 
minden egyes megosztott erőforrás elérésekor kényszerűen a tarto- 
mányvezérlőjéhez rohangál (amelyikhez bootoláskor a Secure 
Channelt nyitotta). A tartományvezérlő pedig azért válaszol neki 
minden teketória és ellenőrzés nélkül akár a legvadabb címtár- 
lekérdezésre is, mert a MASINA már réges-régi jó ismerőse neki. 
Csatornája csak az ismerősöknek van. 


Secure Channel ra 





Nevem: DOMAINYÚZer Jolán 
Jelszavent Mans 


5 MASINA nevű munkaállomásunk a Secure Channelen ke- 
resztül kérdezgeti a címtárat, vajon az erőforrásait odaadhat- 
ja-e az erre ácsingózóknak. 





A tartomány alapértelmezésben - kompatibilitási okokból - sajnos 
nemcsak a csatornásoknak, hanem akárkinek, még Anonymousnak is 
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A Secure Channel fizikai 

valójában nem más, mint 

egy TCP csatorna, mely 
örök időkig" fennáll. 
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Au 


válaszol, hisz ez a feltétele annak, hogy Windows 9x-ek 

is használhassák a címtáradatbázist - de ezt le lehet 

tiltani, és ez a lényeg! Az én hálózatom ne borítsa oda 

a címtárat mindenféle jöttmentnek, csakis azonosított 
felhasználóknak, legyen az akár gép, akár ember! 


Ld 


A meghatalmazotti kapcsolat 

A meghatalmazotti, vagy trust kapcsolat lényege, hogy ha egy 
tartomány hitelesít egy felhasználót, akkor az ő hitelesítését más 
tartományok elfogadják, s a felhasználónak jogosultságok adha- 
tók. Ha idegen tartományban kopogtat a felhasználó, akkor az ot- 
tani DC-k nem kínlódnak az azonosítással, hanem megkeresik azt 
a tartományt, amely felelős a felhasználóért, és felkérik a név-tjel- 
szó ellenőrzésére. 

A folyamat szimulálható a fentebb emlegetett NlTest.EXE prog- 
ramocskával. A /WHOWILL és a /FINDUSER kapcsolókkal meg le- 
het állapítani, melyik tartomány tudná bejelentkeztetni a pa- 
rancssorban megadott felhasználót. A /FINDUSER még csak nem 
is kér tartománynevet: egy puszta loginnév alapján kideríti, hol 
lehetne őt bejelentkeztetni. 

Úgy is fogalmazhatunk, hogy a trustra lépett tartományok , idegen" 
címtárakkal is ékeskednek, vagyis nemcsak saját, hanem távoli cím- 
tár alapján is képesek dönteni a felhasználó beengedéséről. 

Most vizsgáljuk meg a tartományhoz csatlakoztatott munkaállo- 
mást ebből a szempontból. Bejelentkezéskor két címtár közül 
választhatunk: a helyi SAM, és a tartományi címtáradatbázis is 
rendelkezésünkre áll. Vagyis a munkaállomás ,idegen" címtár 
alapján dönt a felhasználó beengedéséről. Mi ez, ha nem trust? 
Ez bizony trust, ha nem is a javából, de a gyengébbjéből. 


Trust tartományvezérlők között 
A kihalófélben lévő Windows NT4 tartományok között kézzel le- 
hetett meghatalmazotti viszonyt felépíteni. 


s a 

D-( DEC) 
a Meghatalmazotti kapcsolat három NT4 tartomány között. 
nB" felhasználói tevékenykedhetnek ,,A" tartományban is. 
nC" és , B" felhasználói kölcsönösen dolgozhatnak egymás 


tartományában is. De mi a helyzet ,, A" és , C" között? 


A nyíl iránya nem tévedés: ,A" 





... a Windows NT 
Workstation és 
Windows 2000 

Professional olyan 

tartományvezérlők, 
melyeknek 
kapcsolatépítési 
képességeit a 
minimális szintre 
szorították. 


tartomány a nyíllal jelölt tarto- 
mányban megbízik. Ennek folyo- 
mánya, hogy , B" felhasználói át- 
sétálhatnak ,A" tartományba, és 
ott bejelentkezhetnek, erőforrá- 
sokhoz kapcsolódhatnak. ,B" és 
C" között kétirányú, kölcsönös a 
bizalom: ezt két egyirányú trust 
létrehozásával lehet kialakítani. 
A nyíl tehát olyan tartományokra 
mutat, amelyek (account)forrás- 
ként szerepelnek a trustban. Ezek 
a kézi kapcsolatok nem tranzi- 
tívek, ami magyarul azt jelenti, 
hogy , A" és ,C" mindaddig nem 
hisz egymásnak, amíg közöttük 
közvetlen kapcsolat nincs. 
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Windows 2000 esetén a gyermektartományok telepítésekor au- 
tomatikusan alakul ki a trust, bár továbbra is lehetőség van kap- 
csolatok kézi kialakítására az Active Directory Domains and 
Trusts eszköz segítségével. Így ábrázoljuk az automatikus meg- 
hatalmazotti kapcsolatot: 


A 5 Meghatalmazotti kapcsolat há- 
rom Windows 2000 tartomány kö- 
zött. Itt mindegyik kapcsolat két- 
irányú és tranzitív, azaz ,,B" és ,,C" 
között is van , átjárás" 


/BNV ZEN 


A meghatalmazotti kapcsolat alapja nem más, mint (minő megle- 
petés!) egy-egy Secure Channel a két tartomány vezérlői között. 
A két domain gépei egymáshoz éppúgy bejelentkeznek, mint azt a 
munkaállomásnál láttuk. Egy terminológiai különbség van csupán: 
azt a fiókot, mellyel bejelentkeznek egymáshoz, nem Computer 
Accountnak, hanem Interdomain Trust Accountnak hívják. A neve 
éppúgy dollárjellel képződik, csak nem a gépnévből, hanem a tar- 
tomány nevéből. Ennek jelszavát a DC-k közösen kezelik. 
Foglaljuk most össze a sok-sok operációs rendszer-változat cím- 
tárkapcsolat-képességeit egy táblázatban: 





Cimtár " kialakítható "A DLLCCAN ÚT aaa 
kejrlestele dol dá c elege E aeáget tte 
száma típusa 

Workstation. SAM ú Kézi, cél Nem 
és egyirányú 
Professional 
NT 4 SAM Sok Kézi, Forrás Nem 
egyirányú és cél 
Server és Active Sok Automa- Forrás Igen 
Advanced — Direc- tikus, és cél 
Server tory kétirányú 


Igen szembetűnő a hasonlóság a munkaállomás-változatok és az NT4 
között: a különbség a kialakítható kapcsolatok számában és irányá- 
ban rejlik! (A munkaállomás ,,címtárában" nem lehet megbízni, az ott 
létrehozott felhasználók és csoportok lokálisak, kitörni nem tudnak.) 
Tehát a Windows NT Workstation és Windows 2000 Professional 
olyan tartományvezérlők, melyeknek kapcsolatépítési képessé- 
geit a minimális szintre szorították. 

Ehhez jön még a maximálisan tíz felhasználói kapcsolat a 
megosztott erőforrásokra, a végrehajtási szálak kezelésének kü- 
lönbözősége, a lemezkezelési lehetőségek (RAID) megnyirbálá- 
sa - de ezzel gyakorlatilag vége is a sornak. 

S hogy mi a fenti ismeretek gyakorlati haszna? Vizsgázáskor jól 
jön, ha annak látjuk a világot, ami, és nem dőlünk be a furfan- 
gos kérdéskészítők szándékos szédítéseinek! 


Fóti Marcell 
marcellf(onetacademia.net 
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A RIS kétféle telepítőkészlettel képes dolgozni. Az egyik a Riprep segítségével 
készített, a másik a CD-ROM, vagy Script alapú telepítőkészlet. 

A Microsoft RIS-sel csupán a Windows XP/2000 Professional telepítését támogatja, 
sem korábbi operációs rendszerek, sem a Windows 2000 Server telepítését nem, 
azonban egy kis trükkel a Windows 2000 Servert meg tudjuk etetni a risetuppal, 
így CD-ROM alapú telepítőkészletet tudunk készíteni a kiszolgálókhoz is. 


CD-ROM alapú telepítőkészlet 

Ez a telepítőkészlet csak kicsit különbözik attól az esettől, ami- 
kor felügyelet nélküli telepítőkészletet használunk egy kiszolgá- 
lón megosztott könyvtárból, amelyhez egy DOS-os MSClient segít- 
ségével csatlakozunk. RIS esetén jó esetben nem kell bootfloppy 
ehhez (ha muszáj, a RIS-es rbfg.exe-vel elkészíthető bootfloppyt 
használunk). A gyalogos válaszfájlos telepítéstől annyiban tér el, 
hogy itt SIF kiterjesztésű a válaszokat tartalmazó állomány, s tar- 
talma kismértékben eltér a hagyományos unattend.txt-től. 

Ez a típusú telepítőkészlet az alapértelmezett, a risetup.exe első 
futtatásakor menthetetlenül létre is jön egy csomag a RIS kiszol- 
gálón a RemoteinstallySetuptEnglish Vmages egy alkönyvtárában. 
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9 Az első telepítőkészlet a RIS Sever telepítésekor elkészül 








Minden, ami a win2000.pro könyvtár alatt található, ehhez a te- 
lepítőkészlethez tartozik. Alatta létrehozhatunk egy $0EM$ ne- 
vű könyvtárat, benne további könyvtárakat és állományokat, 
amelyek telepítéskor az operációs rendszerrel együtt a merevle- 
mezre kerülnek. Például ha C:Wmyfiles könyvtárba szeretnénk ra- 
katni fájlokat a telepített, kész gépre, akkor a $0EM$ könyvtár 
alatt létrehozunk egy C könyvtárat (a kötet neve alapján), ben- 
ne a myfiles könyvtárat, abba pedig belepakoljuk amit le aka- 
runk juttatni a telepítővel az ügyfélgépre. 


á-€ Images 
H-CI win2000.pro 
EC i386 
5-1 $o0em$ 
I Be 
bd Sie 


9 Extra fájlok lejuttatása a telepítés során 





Vörkinú with 


windows / 


Ez például akkor hasznos, ha egy batch fájlt akarunk meghívni az 
első bejelentkezés után a további programok feltelepítéséhez, de 
a lokális administrator/rendszergazda jelszava nem egyezik meg 
a tartománybelivel (ennek minden helyen így kellene lennie), és a 
válaszfájlban nem is akarjuk azt megadni. Így szokás lejuttatni az 
ügyfelekre olyan eszközmeghajtókhoz szükséges állományokat is, 
amelyek nem részei az operációs rendszer telepítőkészletének. 
Alapértelmezésben csak az operációs rendszer telepítését tartal- 
mazza egy ilyen telepítőkészlet, de könnyen alakíthatjuk úgy a te- 
lepítést, hogy az a szükséges programokat is felpakolja rögtön az 
operációs rendszer után. Ehhez a SIF állományt kell módosítani, 
valamint a programokat elő kell készíteni a felügyelet nélküli te- 
lepítéshez. Az Office2000/XP-hez például az Office Resource 
Kitben található telepítő varázslóval gyárthatunk konfigurációs ál- 
lományokat, amelyek segítségével parancssorból telepíthető az 
Office. Az Internet Explorer Administration Kit segítségével olyan 
telepítőkészlet készíthető az IE-hez, mely ráadásul teljes körű 
beállítási lehetőséget is nyújt (proxy, dial stb.). Telepítőkészletek 
gyártásához a Wininstall LE, vagy a Systems Management Server 
2.0-ben található SMS Installer használható. Mindkettővel telepí- 
tőcsomagba gyűrhetők 
az egyébként nem ilyen 
telepítésű, régi alkalma- 
zások. Akár a sysdiffet is 
használhatjuk felügyelet 
nélküli telepítőkészletek 
gyártásához, vagy tele- 
píthetjük a programokat 
Group Policy segítségével 
is. De térjünk vissza az 
operációs rendszerhez. 
A CD-ROM alapú telepí- 
tőkészlet nagy előnye, 
hogy rendkívül rugalma- 
san változtatható, többféleképp telepíthetjük az operációs rend- 
szert ugyanazzal a telepítőkészlettel, csupán a válaszokat tartal- 
mazó állományban - a SIF fájlban - kell változtatnunk. Helykímé- 
lő megoldás, mert a programokhoz is csak egyszer kell létrehozni 
a telepítőkészletet, azt külön batch fájlokkal szabályozva külön- 
böző végeredményhez juthatunk. Hátránya a Riprep alapúval 
szemben, hogy a kívánt eredmény eléréséhez kicsit többet kell 
foglalkozni a programok előkészítésével. 


Csalás: Windows 2000 Server telepítőkészlet létrehozása 
CDROM alapú telepítőkészletet a risetup segítségével tudunk 


eNüg:. Na: 


4) ATA 7 


.N 


(zsau 


Alapértelmezésben csak 
az operációs rendszer 
telepítését tartalmazza 

egy ilyen telepítőkészlet, 

de könnyen alakíthatjuk 
úgy a telepítést, hogy az 

a szükséges programokat 
is felpakolja rögtön az 

operációs rendszer után. 


le 


(IV. rész) / 


RIS 


Ha ezt mégis szeretnénk, 


13 





Alaphelyzetben a 
Riprep telepítőkészletből 
felhúzott gépek esetén 
a telepítés nem vizsgálja 


a -pnp parancssori 


létrehozni, azonban ez Windows  XP/2000 
. . Professional telepítőkészlet létrehozását engedélye- 
zi csupán. Be kell csapni a varázslót ahhoz, hogy 
megegye a Windows 2000 Server telepítőkészletet is. 
Elkészítés az alábbi recept szerint: 
B A Windows 2000 Server telepítő CD-ről másoljuk az 1386 könyv- 
tárat a merevlemezre. 
8 Egyszerű szövegszerkesztővel nyissuk meg a txtsetup.sif fájlt 
miután levettük az írásvédettséget. 
B A [SetupData)] részben a ProductType értékét 
állítsuk 1-ről 0-ra, majd mentsük az állományt. 
"0 Futtassuk a risetup.exe-t, és a már ismert módon 
a varázsló segítségével készítsük el a kiszolgálón a telepí- 
tőkészletet. 
"? Keressük meg a txtsetup.sif fájlt az elkészített telepítő készlet 
állományai között, és állítsuk vissza a ProductType értékét 1-re. 
Ezzel elkészült a telepítőkészlet, amelyet használhatunk RIS-sel, 
azonban mivel kiszolgálóról van szó, a hozzá tartozó SIF fájlban 
módosításokat kell végrehajtanunk - lásd később. 


Riprep alapú telepítőkészlet 
Ebben az esetben nem teszünk mást, mint a teljesen előkészí- 
tett minta ügyfélgép pontos lenyomatát másoljuk a kiszolgáló- 
ra olyan formában, hogy az a másik munkaállomáson használha- 
tó legyen (klónozás). 
A Riprep alapú lenyomatok több helyet foglalnak, mint a CD- 
ROM alapúak, mert ezek az ügyfél merevlemezének másolatai, 
amely nemcsak az operációs rendszert, hanem minden telepített 
programot is tartalmaznak. 
Ahhoz, hogy egy kiszolgálón Riprep alapú telepítőkészletet tá- 
roljunk, már legalább egy CD-ROM alapú telepítőnek ott kell len- 
nie. A nyelvi verziónak és a Service Pack verziónak is meg kell 
egyeznie. További szüksé- 
ges feltétel, hogy az ügy- 
félnek, amelyről a telepítő- 
készletet készítjük, sajnos 
csak egy partíciój 
Ha több partíciója van, ak- 
kor figyelmeztető üzenet 
jelenik meg és a program 
csak a rendszerpartíciót 
(amelyen a Winnt könyvtár 
található) másolja le. Eb- 
ből következik, hogy az in- 
dító-(boot) és a rendszer- 
partíciónak (system) egy- 
nek kell lennie. Figyeljünk 
arra is, hogy a célszámítógépnek legalább akkora vagy nagyobb 
merevlemeze legyen, mint amelyről a lenyomatot készítjük, va- 
lamint ugyanaz legyen a HAL-ja (ACPI vagy nem ACPI). 
Riprep alapú telepítőkészlet létrehozásához az előkészített, te- 
letelepített munkaállomásról kapcsolódjunk ahhoz a RIS kiszol- 
gálóhoz, amelyen tárolni akarjuk a telepítőkészletet. A Reminst 
megosztás alól az AdminW386 könyvtárból futtassuk a Riprep.exe 
programot. Ez az előkészítő varázsló (Remote Installation 
Preparation Wizard), amely a következőket teszi: 
"8 Ellenőrzi, hogy vannak-e nyitott állományok. Ha talál ilyet, fel- 
szólít, hogy zárjuk be azokat és indítsuk újra a programot. 
"8 Ellenőrzi, hogy vannak-e olyan ismert vagy ismeretlen szolgál- 
tatások, amelyek esetleg írhatnak a lemezre. Ha talál ilyen 
futó szolgáltatást, akkor felszólít annak leállítására. 
8 Bekéri annak a RIS kiszolgálónak a nevét, amelyen a lenyoma- 
tot tárolni akarjuk. 
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- Bekéri azt az alkönyvtárat, ahova létre akarjuk hozni a lenyo- 
matot. 

8 Bekéri a megjelenítendő leírást és kiegészítő szöveget (Friendly 
Description, Help text) 

0 Létrehoz egy alapértelmezett Riprep.sif fájlt a SysPrep felügye- 
let nélküli beállításait használva. 

Miután minden kérdést megválaszoltunk, a Riprep előkészíti a 

gépet a telepítőkészlet létrehozásához, majd elkezdi a kiszolgá- 

lóra másolni a fájlokat. Amikor ezzel végzett, kikapcsolja a mun- 

kaállomást. Ha újraindítjuk, egy varázsló fog elindulni, mintha 

csak a Sysprepet futtatnánk. 


A Riprep telepítőkészlet elkészítése 
A kiszolgálón a Riprep az alábbi könyvtárstruktúrát hozza létre: 





Bi 4 
B-(a Mirror1 
i 5 a UserData 
HI Documents and Settings 
CI Program Files 















5 Riprep telepítőkészlet (klón) a RIS kiszolgálón 


Három fájl is létrejön, melyek a Riprep alapú lenyomatról tartal- 

maznak információt (Riprep.log, Bootcode.dat és Imirror.dat) : 

"B Riprep.log: Ez a fájl a Riprep.exe futásának naplója. Az esetle- 
ges hibaüzenetek (például nyitott vagy titkosított fájlok 
miatt) ide kerülnek bejegyzésre olyan információk kíséreté- 
ben, mint a kiszolgáló neve, leírása stb. Ez a fájl az 1386 
könyvtárban található. 

"8 Bootcode.dat: Ez a fájl a számítógép bootszektorát tartalmaz- 
Za. Ez az egyik oka annak, hogy a telepítendő számítógépben 
legalább akkora merevlemezre van szükség, mint amiről a le- 
nyomat készült. A fájl az I386Mirror1 könyvtárban található. 

b Imirror.dat: Ez a fájl a Ripreppel klónozott számítógépről tar- 
talmaz információt. Nem olvasható (hacsak nem készítünk 
róla egy hexa-dumpot). A meghajtó betűjeléről, a telepítési 
könyvtárról, a hardver absztrakciós réteg típusáról (HAL), az 
ARC útvonalról és hasonlókról tartalmaz információkat. 

Alaphelyzetben a Riprep telepítőkészletből felhúzott gépek esetén 
a telepítés nem vizsgálja a hardvert. Ha ezt mégis szeretnénk, ak- 
kor használjuk a -pnp parancssori kapcsolót a telepítőkészlet létre- 
hozásakor (riprep -pnp) . Ezután működni fog a Plug and Play kiér- 
tékelés, így különböző alkatrészek esetén is működni fog a klón. 
Ha egyszer elkészítettük a Riprep alapú telepítőkészletet, abban 
változtatni nem lehet. Ha bármit meg szeretnénk változtatni a 
beállításokon, akkor a mintaként használt gépről újra és újra el 
kell készíteni a telepítőkészletet. Sok helyet foglal, bár a SIS jó- 
tékony munkája nyomán minden állomány igazából csak egyszer 
foglalja a helyet a kiszolgálón. Kevésbé rugalmas megoldás ez, 
cserébe kevesebb nyűggel jár az elkészítése. 


A RIS válaszfájlok 

Az egyes munkaállomások telepítéséhez a válaszfájl a telepítő- 
készletek minta válaszfájljából jön létre a munkaállomás telepí- 
tése előtt közvetlenül CIW (Client Installation Wizard) képernyő- 
kön megadott adatok beépítésével. 

A mintafájlokat fontos előkészíteni, ugyanis ezzel tehetjük valóban 
felügyelet nélkülivé a telepítést, hisz az ebben található válaszok 
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irányítják a munkaállomások telepítését. Minden telepítőkészlethez 
legalább egy minta válaszfájl tartozik. Az alapértelmezett mintafájl 
az első Risetup első futtatásával jön létre, a telepítőkészlet 
I3Z86Wemplates könyvtárában ristndrd.sif néven. 

Ha ennek segítségével indítunk egy telepítést, akkor az nem fog 
működni felügyelet nélkül, mert egy fontos dolog, a telepítéshez 
szükséges termékkód hiányzik belőle. Ezt az egy adatot mindenképp 
érdemes beletenni a [UserData] szakaszba a következő formában: 


ProductID-"XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" 


Egy telepítőkészlethez több ilyen minta válaszfájl is tartozhat, 
így tudunk ugyanabból a forrásból többféle végeredményre jut- 
ni. Ehhez nem kell mást tenni, mint a meglevő SIF fájlt lemá- 
soljuk ugyanabba a könyvtárba, majd azt módosítjuk, és elment- 
jük bármilyen néven SIF kiterjesztéssel. Egyszerű, nem? Készít- 
hetünk ilyen válaszfájlt a Setup Manager Wizard segítségével is, 
de a meglevőt is megváltoztathatjuk vele. Ez a varázsló a Win- 
dows 2000 Support Tools része. Ha nem akarjuk telepíteni, ak- 
kor a Windows 2000 telepítő CD-n levő Ysupportítoolstdeploy.cab 
fájlból szedjük ki a setupmgr.exe fájlt és máris varázsolhatunk. 
Mindenkinek ajánlom figyelmébe az ugyanitt található unat- 
tend.doc fájlt is, amelyben megtalálható a válaszfájlokban 
használható paraméterek magyarázata. Nézzük, mit tartalmaz 
egy ilyen válaszfájl és mit érdemes megváltoztatni benne. 

A SIF fájl nem más, mint egy felügyelet nélküli telepítési válasz- 
fájl a RIS-sel való telepítéshez szükséges kiegészítésekkel. Né- 
hány fontosabb bejegyzés: 


A [Data] szakasz 

Ez a mintafájl első szakasza, amelyben a Risetup.exe helyezi el 

a következőket: 

"0 floppyless — "1" 
Ebből tudja a telepítő, hogy hálózati telepítés zajlik. 

"8 msdosinitiated — "1" 
Azt jelenti, hogy a telepítés nem CD-ROM-ról vagy floppy- 
lemezről indult. 

6 OriSrc-YANVoSERVERNAMESo  ReminstV9INSTALLPATH9o 
MoMACHINETYPE9o 
A telepítő fájlok elérési útvonala. A változók akkor kapnak 
értéket, amikor az ügyfél ténylegesen használja a mintát. A 
BINL szolgáltatás a fájlban lévő változókat helyettesíti a ki- 
szolgáló által megadott értékekkel (például a Servername he- 
lyére a RIS kiszolgáló neve kerül). Így a minta a szervezet 
bármely RIS kiszolgálóján használható. Ennek az értéknek a 
megadásával megkíméljük a felhasználót a telepítési útvo- 
nal mindenkori megadásától. 

0 OriTyp - "4" 
Ez az érték azért van 4-re állítva, mert távoli telepítésről van 
szó. Ha a telepítés helyi CD-ROM-ról indul, az érték 5. 

Ezeket az értékeket a RIS kiszolgáló állítja be, és módosításuk- 

ra nincs szükség. 


A [SetupData)] szakasz 
A minta [SetupData] szakasza nem RIS-specifikus, minden 
felügyelet nélküli válaszfájlban használható. Ez a szakasz a te- 
lepítő szöveges módjára vonatkozik és két értéket ad meg: 
"6 OsLoadoptions - "/noguiboot /fastdetect" 
Utasítja a Telepítőt, hogy a telepítést grafikus felhasználói felü- 
let (splash screen) nélkül indítsa, és használjon ,fastdetect"-et. 
"8 SetupSourceDevice-" WevicelLanmanRedirector 
MYSSERVERNAMEJoRemIlnstY9oINSTALLPATH9o" 
Elérési útvonal a szöveges módú telepítéshez. 
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Az [Unattended] szakasz 

Bár ez a szakasz nem RIS specifikus, mégis van pár dolog, 

amit itt érdemes beállítani az alapértelmezéstől eltérően. 

"B FileSystem - LeaveAlone 
Ez a paraméter mondja meg, hogy a partíció, amire telepí- 
tünk NTFS legyen-e, vagy sem. Érdemes ezt az értéket Con- 
vertNTFS-re állítani. 

"8 ExtendOEMPartition — 0 
Alapértelmezésben ez O, de ha 1-re állítjuk, akkor kiterjeszti 
a partíciót amekkorára csak lehet (csak NTFS partíciókkal 
tudja ezt megtenni, tehát a FileSystem paramétert ez esetben 
ConvertNTFS-re kell állítani). 

A [UserData] szakasz 

Alapértelmezésben így néz ki: 

(userData)] 

FullName - "XUSERFIRSTNAMEX XUSERLASTNAMEZ" 


OrgName z "XORGNAMEJ" 
ComputerName - XMACHINENAMEZK 


5 Ristndrd.sif UserData szakasza 


Látható, hogy itt is csupa változóból állnak az értékek, amelyek 
a konkrét telepítés során kapnak valódi tartalmat. 

Már az előbb szóltam arról, hogy ide be kell rakni egy ProductID 
nevű paramétert, mert anélkül a telepítő meg fog állni és várni 
fog a kulcs megadására. 


A [GuiUnattended] szakasz 

Az alapértelmezett beállítások mellett itt lehet megadni a loká- 
lis Administrator jelszavát, valamint azt is, hogy belépjen-e a 
telepítés befejezése után az első boot után további parancsok 
végrehajtása végett, vagy sem. 

Annak érdekében, hogy a helyi Administrator automatikusan be- 
lépjen az első boot után, adjuk hozzá ehhez a szakaszhoz az 
AutoLogon paramétert 1-es értékkel, majd az AutoLogonCount pa- 
raméterrel adjuk meg hányadik bootig lépjen be automatikusan. 


[Guiunattended]l 
AdminPassword-po98iuz 
AutoLogon-Yes 
AutOoLOogoncount -1 
oEmskipRegional1-1 
Timezone-XTIMEZONE? 
oemskipwelcome-1 


5 Egy átalakított [GuiUnattended] szakasz 


"8 OEMSkipReginal — 1 
Ez a paraméter biztosítja, hogy a telepítő grafikus szakaszá- 
ban kimaradjanak a Regionális beállításokra vonatkozó ké- 
pernyők. Létrehozható egy [RegionalSettings] szakasz is, 
amellyel szabályozhatóak a Regionális beállítások. 
"8 OEMSkipWelcome - 1 
Ez a beállítás biztosítja, hogy a telepítés során kimaradjon 
a legelső üdvözlő képernyő. 
TimeZone - 9oTIMEZONE9o 
Ennek a paraméternek magunk is adhatunk értéket. Minden 
időzónának van egy két, vagy három számból álló kódja. Ha 
így hagyjuk, ahogy fentebb látható, akkor a kiszolgáló idő- 
zónáját fogja felvenni a munkaállomás. 


o 


A [RegionalSettings] szakasz 
Ez nem szerepel az alapértelmezett válaszfájlban. Az alábbi pél- 
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dán az látható, hogy az operációs rendszer és a fel- 
használók alapértelmezett területi beállítása a ma- 
gyar, valamint a billentyűzet kiosztások közül a ma- 
gyar és az angol van telepítve. 
(Regionalsettings] 
LanguageGroup-1 , 2 
SsystemLocale:-0000040£ 


userLocale-0000040£ 
InplutLocale-040e:0000040£e, 0409:00000409 


5 Magyar területi beállítások 


A LanguageGroup kódokról bővebben a már emlegetett unatten- 
ded.doc-ban lehet olvasni, csak annyit hogy ez adja meg a te- 
lepítendő nyelvi csoportokat. Ahhoz, hogy magyar területi beál- 
lítás legyen, kell a Central Europe nyelvi csoport is, ez a 2-es 
kódú, míg az egyes a Western Europe and United States nyelvi 
csoport. 

A SystemLocale és UserLocale paraméterhez is kódokat kell ren- 
delni, amelyeket a Microsoft weblapjain találhatunk meg. A fenti 
példánál maradva a 409 végű az angol, a 40e végű a magyar. Az 
InputLocale paraméternek megadott első érték lesz az 
alapértelmezett, esetünkben a magyar. 


A [Components] szakasz 

Ő sem található meg az alapértelmezett válaszfájlban, de érdemes 
létrehozni, ugyanis így tudjuk szabályozni, hogy mely eszközök 
települjenek, illetve ne települjenek az operációs rendszerrel. 
Nagyon hosszú lenne a sor, ha mindet felsorolnám, inkább uta- 
lok újból az unattend.doc fájlra. Azért néhány példa: 

A hyperterminál letiltása: 

8 hypertrm - off 

Néhány játék letiltása (de akkor mire jó az egész? A szerk.): 

"8 minesweeper-off 

"b pinball-off 

b solitairesoff 


A [GuiRunOnce] szakasz 

A CD-ROM alapú telepítőkészleteknél fontos ez a rész, itt adhat- 
juk meg az első automatikus belépés utáni parancsot például az 
alábbi formában: 

"8 Commando-"c:Wnstall.bat" 

A példában szereplő Install.bat-ot az ismertetett $0EM$ mód- 
szerrel lejuttatjuk az ügyfélre, a batch segítségével pedig egy 
hálózati meghajtóról telepíthetjük a szükséges alkalmazásokat. 
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A [Remotelnstall] szakasz 

"8 Repartition — Yes vagy No 
Ha Yes az érték, akkor a munkaállomásról minden partíciót 
letöröl a telepítő, majd létrehoz egy újat. Ezt a paramétert 
elhelyezhetjük a válaszfájlok [Unattended] szakaszába is. 
Ha No az értéke, akkor a telepítő megáll ott, ahol a telepí- 
tés során a partícionálást lehet megtenni. 

8 UseWholedisk- Yes vagy No 
Yes érték esetén az egész merevlemez felhasználásra kerül. 


Az [Oschooser] szakasz 

Az [Oschooser] szakasz néhány olyan változót tartalmaz, ame- 

lyek megjelennek az operációs rendszer kiválasztásakor. Amikor 

először futtatjuk a Risetup.exe fájlt, vagy új lenyomatot helyez- 
tünk el a kiszolgálón, az akkor megadott név és leírás kerül a fájl- 
nak ebbe a szakaszába. Alapértelmezett beállítások a következők: 

8 Description -"Microsoft Windows 2000 Professional" 
Operációs rendszer választásakor ezt a nevet fogja látni a 
felhasználó. 

-8 Help -"Automatically installs Windows 2000 Professional on the 
computer without prompting the user for input. 

A CIW-ben megjelenő leírás. 

8 LaunchFile-"Installpath MachinetypeNTemplatestőtartrom.com" 
A megadott fájl letöltésére és futtatására utasítja a munka- 
állomást. A fájl nem Win32? API formátumú futtatható ál- 
lomány, hanem rendszerindító fájl (boot image), mint pél- 
dául a Startrom.com, vagy más független szoftverfejlesztők 
által készített PXE program. 

8 ImageType - "Flat" 

A lenyomat típusát jelzi. Ne változtassuk meg, mivel a CD- 

ROM és a Riprep alapú SIF-ek nem felcserélhetőek. 

Version-"5.0" 

Az operációs rendszer verziója. 

Az itt említett változók közül az első kettő kivételével ne vál- 

toztassuk a többit, mert nem cserélhetők fel a Riprep alapú és 

a CD-ROM alapú telepítéshez használt válaszfájlok. 

Az utolsó részben megnézzük hogyan lehet több telephely ese- 

tén a RIS kiszolgálókat szinkronban tartani, valamint az Ügyfél 

telepítő Varázsló (CIW) képernyőket fogjuk átszabni. 


Dorner Csilla 
MCSE 
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Internettörvény 
vagy az elektronikus 
kereskedelem szabályozása? 


A 2001. év karácsonyán az információs társadalom tagjai is megkapták a maguk 
ajándékát a törvényhozástól - az Internettörvényt (2001. évi CVIII. törvény). 
Kérdés, hogy valóban Internettörvény született-e, azaz a jogalkotó ténylegesen 
kiterjesztette-e a jogi szabályozás hatósugarát a háló valamennyi jelenségére, vagy 
csupán az elektronikus kereskedelem, a gazdasági kapcsolatok körén belül maradt. 


Kérdésünkre a választ a törvény hatályát szabályozó szakasz 
elemzése adja meg: 


A törvény az elektronikus kereskedelmi szolgáltatást olyan 
információs társadalommal összefüggő szolgáltatásnak de- 
finiálja, amelynek célja áruk, illetőleg szolgáltatások üzlet- 
szerű értékesítése, beszerzése, cseréje. 


Mint látjuk, a kereskedelem hagyományos fogalma tevődik át az 
információs társadalmi szintre. A teljességhez tehát elengedhe- 
tetlen az információs társadalommal összefüggő szolgáltatás fo- 
galmi meghatározása is, amely a törvény értelmezésében: 


elektronikus úton, távollevők részére, ellenszolgáltatás 
fejében nyújtott szolgáltatás, amelynek igénybevételét a 
szolgáltatás igénybevevője egyedileg kezdeményezi, továb- 
bá mindazon ellenszolgáltatás nélkül, elektronikus úton, 
távollevők részére, az igénybevevő egyedi kezdeményezé- 
sére nyújtott szolgáltatás, amelyek a szolgáltató, illetve az 
igénybevevő részéről nem az Alkotmány által biztosított 
véleményszabadság gyakorlásának körébe tartoznak." 


E kissé szokatlan megfogalmazásból látszik, hogy addig, amíg 
az e-commerce (elektronikus kereskedelem) témaköre alatt ha- 
gyományosan a B2B (business to business) vagy B2C (business 
to consumer) kapcsolatot értjük, addig a törvény a C2C, vagyis 
az állampolgárok egymás közötti kapcsolatát is a szabályo- 
zás hatálya alá vonta. (!) 

Az, hogy ténylegesen mi tartozik a véleménynyilvánítás szabadsá- 
ga körébe, nyilván a bírói gyakorlat függvényében alakul majd ki. 
A B2B kapcsolat hagyományosan a nagykereskedelem, ahol az 
üzleti élet egymással tartós kapcsolatban álló résztvevői egymás 
között speciális zárt hálózaton, egyedi kommunikációs szabályok 
szerint, kidolgozott szerződéses keretek között kötik meg a jog- 
ügyleteket. E körben tehát kevésbé szükséges a fokozott jogi vé- 
delem. A B2C nyilvános hálózaton, a fogyasztók részére történő 
értékesítés, ahol jellemzően a szolgáltató által diktált egyoldalú 
szerződéses feltételek (Általános Szerződési Feltételek) alapján 
zajlik az üzletkötés, ismeretlen felek közötti alkalmi jogügyletek 
jönnek létre. Hagyományosan ez az a terület, amely speciális jo- 
gi szabályozásért kiált, hiszen itt van kiszolgáltatva a fogyasztó, 
és itt kell a jogalkotónak konkrét szabályokkal biztosítania a vé- 
delmet. Ezért is tűnik az európai szabályozástól eltérő magyar 
definíció kissé szerencsétlennek, mivel nem ez a jogalkotói szán- 
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dék látszik a szövegezés mögött. Ellenkezőleg, a törvény nem a 
speciális védelem biztosítására, hanem az Internet lehető 
legszélesebb körű szabályozására törekszik akkor, amikor az 
ingyenesen, nem ellenszolgáltatás fejében nyújtott információs 
társadalmi szolgáltatást is hatálya alá vonja. 

A törvény másrészt kiveszi hatálya alól az elektronikus levélcím 
fenntartását, mint információs szolgáltatást, és az elektronikus 
magánlevelezést. 

A területi hatály is érdekesen került meghatározásra, mivel a 
Magyar Köztársaság területéről nyújtott információs társadalmi 
szolgáltatás mellett az ide irányulót is a szabályozás körébe kí- 
vánja vonni. A törvényértelmező rendelkezése szerint azt, hogy 
a Magyar Köztársaság területére irányul-e a szolgáltatás elsősor- 
ban a tartalomból, a használt nyelvből, a feltüntetett fizető- 
eszközből kell(ene) megállapítani. 

A törvény hatálya alá tartozó szolgáltatókat meglehetősen 
széleskörű adatszolgáltatási kötelezettség terheli. Elektronikus 
úton közvetlenül és folyamatosan közzé kell tenniük a nevüket, 
képviselőjük nevét, lakcímét, 
székhelyét, telephelyét, elérhe- 
tőségeit (különösen az e-mail cí- 
met), amennyiben a tevékenység 
végzéséhez valamilyen nyilván- 
tartásba vételi kötelezettség tel- 
jesítése szükséges, úgy a nyil- 
vántartásba vevő hatóság meg- 
nevezését és a nyilvántartásba 
vételi számot, engedélyköteles 
tevékenység esetén az engedé- 
lyező hatóságot és az engedély 
számát, a szakmai és etikai 
előírásokra való hivatkozást azok elérhetőségének megjelölésé- 
vel, a szolgáltató adószámát, szakmai kamarai tagságát, tudomá- 
nyos szakmai fokozatát és megszerzésének helyét, akkreditáló 
okiratának adatait, elérhetőségét, minősítését, a fogyasztóvédel- 
mi szabályoknak megfelelő tájékoztatást. 

A törvény már ismertetett módon kiszélesített hatálya azonban 
azt eredményezi, hogy ha nem soroljuk a véleménynyilvánítás 
szabadsága körébe tartozónak a hobbi site-ok számottevő ré- 
szét, akkor pl. kedvenc receptjeit a hálón ingyenesen hozzáfér- 
hetővé tevő akadémikusnak is minden felsorolt információt 
közölnie kell magáról. 

Az adatszolgáltatási kötelezettség körében felsorolt engedélyre 
vonatkozó információadást külön szükséges kiemelnünk, mivel 
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az európai szabályozással összhangban a törvény ki- 
, fejezetten kizárja azt, hogy magát az információs 
társadalmi szolgáltatás folytatását külön engedély- 
hez kössék. Ilyen szolgáltatást bármely természetes, 
illetve jogi személy, vagy jogi személyiség nélküli szerve- 
zet végezhet. Az előírt engedély ez esetben tehát arra az alap- 
tevékenységre (pl. csomagküldő tevékenység, on-line újság 
kiadása stb.) vonatkozik, amelyet elektronikus úton, távollevők 
részére, ellenszolgáltatás fejében nyújtanak. 
A felsorolt, és a szolgáltató személyével összefüggő adatszolgál- 
tatási kötelezettségen túl a törvény további, a szolgáltatás ter- 
mészetével összefüggő információk folyamatos közlését írja elő, 
így a szolgáltatás ellenértékhez kötését, az ellenérték mértékét, 
a teljesítés módját ugyancsak folyamatosan, elektronikus úton 
közvetlenül hozzáférhetővé kell tenni. A tájékoztatásnak egyér- 
telműnek és közérthetőnek kell lennie, és arra is ki kell terjed- 
nie, hogy az ellenérték a közterheket is tartalmazza-e, illetve az 
igénybevevőhöz eljuttatás költségeit fedezi-e. 
A törvény szankcionálja azokat a szolgáltatókat, akik nem tesz- 
nek eleget közlési kötelezettségüknek, mivel a Hírközlési Fel- 
ügyelet 500000.-Ft-ig terjedő bírságot szabhat ki a kötele- 
zettségét megszegő szolgáltatóval szemben. Természetesen a 
szolgáltató nem mentesül az egyéb jogszabályban, a tevékeny- 
ségre specifikusan vonatkozó előírások betartása alól sem, így 
halmozott bírság is elképzelhető, ha pl. a kereskedőt a Fogyasz- 
tóvédelmi Felügyelőség is elmarasztalja. 
Az elektronikus kereskedelem témakörében az egyik legérzéke- 
nyebb kérdés, hogy milyen pillanattól jön létre a szerződés, és 
ehhez milyen aktív tevékenység szükséges a felek részéről. Ha 
egyszerű klikkeléssel a fogyasztó kötelezettséget vállalna az olda- 
lon hirdetett áru átvételére és ellenértékének kifizetésére, számos 
pert lehetne indítani az ily módon létrejövő szerződések megtá- 
madására, amikor a megtámadási ok a tényleges szerződéses aka- 
rat hiánya, tévedés vagy megtévesztés lenne. Az Európai Unió 
2000/31 Irányelvének jogi megoldásával összhangban ezért a 
magyar jogi megoldás is több lépcső egymásra épüléséhez köti a 
szerződés létrejöttét. Első feltétel, hogy a fogyasztó még az aján- 
lat elküldését megelőzően hozzáférhessen az általános szerződé- 
si feltételekhez oly módon, hogy azt tárolhassa és bármikor elő- 
hívhassa. A szolgáltató továbbá előzetesen köteles tájékoztatni a 
fogyasztót a szerződés megkötéséhez szükséges technikai lépé- 
sekről, arról, hogy azt írásba foglalt szerződésnek minősíti-e, a 
szolgáltató iktatja-e a szerződést, az iktatott szerződés utóbb 
hozzáférhető lesz-e, a fogyasztó az esetleges hibás adatbevitelt 
utóbb hogyan tudja korrigálni, a szerződés nyelvéről, valamint ar- 
ról a magatartási kódexről, amelynek a szolgáltató aláveti magát. 
A felsorolásból két tényezőt érdemes kiemelni: Az írásbeliséghez 
egyes jogszabályok jogkövetkezményeket fűznek, így bizonyos 
szerződések érvényességéhez elengedhetetlen azok írásba fogla- 
lása. Az elektronikus úton kötött szerződések tehát nem a jogsza- 
bály erejénél fogva minősülnek írásbelinek, hanem csak akkor, ha 
azokat a szolgáltató akként kezeli. Az elektronikus aláírásról szó- 
ló törvény szerinti minősített vagy fokozott biztonságú aláírással 
ellátott okiratok nyilvánvalóan írásbelinek is minősülnek, más 
esetben azonban az írásbeliséghez fűzött jogkövetkezmények már 
nem állapíthatók meg ilyen egyértelműen. A másik sajátosság a 
magatartási kódexre hivatkozás, amely a co-regulation, azaz az 
állami- és az önszabályozás együttességének előrevetítése, 
ugyancsak az Európai Unió irányelvével összhangban. 
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A törvény szabályozása kogens, amely azt jelenti, hogy a felek 
közös akarattal sem térhetnek el a törvény előírásaitól. 
Azonban a B2B viszonyban, vagyis az üzleti szférán belüli szer- 
ződéses kapcsolatok körében a jogalkotó maga is megengedi az 
eltérést a szolgáltatót terhelő speciális információ szolgáltatási 
kötelezettségek vonatkozásában. 

A fogyasztó további biztonságát szolgálja az, hogy számára le- 
hetőséget kell biztosítani az adatbeviteli hibák azonosítására és 
kijavítására. Ha ilyen lehetőséget nem biztosít a fogyasztó szá- 
mára a szolgáltató, úgy a fogyasztó ajánlatához nincs kötve. 

A szerződés létrejöttéhez a polgári jog általános szabályai sze- 
rint is a két fél egybehangzó akaratnyilvánítása szükséges. Az 
akaratnyilvánítást azonban nem szükséges a feleknek egyidejű- 
leg vagy azonos helyszínen megtenniük, a nyilatkozatok idő- 
pontja és módja is eltérhet egymástól. A távollevők közötti szer- 
ződéskötések tipikusan ilyen időben és helyszín tekintetében 
különböző nyilatkozatokkal jönnek létre. Az üzleti életben ezért 
alakult ki hagyományosan az ajánlat - és annak elfogadása, 
mint két egymástól eltérő nyilatkozat, amelyek együttesen hoz- 
zák létre a szerződést a felek között. Az elektronikus úton kö- 
tött szerződéseknél tehát a szolgáltató ajánlattételi felhívást 
tesz közzé, amelyre a fogyasztó a megfelelő technikai úton 
megteszi a maga ajánlatát. Ez többnyire e-mail küldéssel vagy 
egyszerű klikkeléssel történik. A fogyasztó ajánlatához ezt kö- 
vetően 48 óráig kötve van, vagyis ha a szolgáltató ez időtar- 
tam alatt visszaigazolja az ajánlat megérkezését, vagyis azt el- 
fogadja, a szerződés létrejön. Az ajánlat és annak visszaigazo- 
lása akkor tekinthető a másik félhez megérkezettnek, amikor az 
számára hozzáférhetővé válik. Tehát nem az elolvasás vagy fel- 
dolgozás ténye, hanem a hozzáférhetővé válás a döntő. A jog- 
alkotó a szubjektív tudomásszerzés helyett az objektív megérke- 
zést tette relevánssá. E tekintetben természetesen harmonizál a 
megoldás a hagyományos polgári jogi megoldásokkal, hiszen a 
hagyományos postai úton küldött ajánlat esetében sem annak 
elolvasása, hanem a címzettnek történő elküldése és az oda va- 
ló megérkezése a szerződést keletkeztető tény. 

A BZ2B körben itt is megengedett az eltérés, tehát a felek megál- 
lapodhatnak abban, hogy az ajánlat visszaigazolását nem igény- 
lik, vagy hogy a szolgáltató nem biztosítja az igénylőnek az 
adatbeviteli hibák korrigálásának lehetőségét. Az ajánlat és a 
visszaigazolás megérkezésére vonatkozó előírásoktól azonban 
még e körben sem térhetnek el a felek. 

A törvény hatályának elemzésekor említettekkel szemben az elekt- 
ronikus úton kötött szerződésekre vonatkozó szabályokat kiter- 
jeszti a jogalkotó az elektronikus levelezés vagy azzal egyenérté- 
kű kommunikáció ( e-mail, spam) útján létrejövő szerződésekre is. 


Az elektronikus kereskedelem körén túl - amint azt a már elem- 
zett jogalkotói szándék is mutatja - az Internet számos egyéb 
kérdésre próbál meg jogalkotói választ adni a törvény. Így az 
amerikai és európai szabályozással összhangban rendezi a szol- 
gáltatók egyes tevékenysége esetén felmerülő felelősség kérdé- 
sét, továbbá a szerzői jog jogsérelem esetére bevezeti a notice 
and take down eljárást. 


E speciális rendelkezések ismertetését a következő számban ta- 
lálják meg. 


Dr. Mayer Erika 
Nádas 8. Mayer Ügyvédi Iroda 
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ASP Suli: 


Wap alapok 


Előző számunkban bemutattuk a WML nyelv alapjait. Megtudtuk, hogy a wapos 
szolgáltatások kiszolgáló oldalról gyakorlatilag alig különböznek a hagyományos webes 
szolgáltatásoktól - ilyen alapon néhány apró beállítás után akár az Internet 
Information Services is képes wapos kiszolgálóként üzemelni. Akkor pedig már annak 
sincs akadálya, hogy a WML oldalakat dinamikusan, az ASP segítségével állítsuk elő! 


Mielőtt nekikezdenénk... 

.. megismételném az előző számban már leírtakat. A wapos fej- 
lesztés egyik legnagyobb problémája, hogy a szintaktikai és 
egyéb hibák általában csak a WML kódot lefordító átjárón, a WML 
gateway-en derülnek ki. Ha a tesztelést hagyományos telefonról 
végezzük, ez a gateway a mobilszolgáltató szerverén működik, és 
a hibák pontos jellegéről nem kapunk értesítést sem a telefon, 
sem pedig a kiszolgáló irányába. Ennél sokkal jobb, ha olyan esz- 
közöket használunk a teszteléshez, amelyek a szemünk láttára 
elvégzik a gateway funkciókat is. Egy ilyen, nagyon jól használ- 
ható fejlesztőkészlet az Openwave [2] címéről letölthető SDK és 
emulátor, amelyet cikkünk során is használni fogunk. Az SDK 
4.1-es verziója rövidebb, kompaktabb, jól használható, az 5.0-s 
pedig szinte egy teljeskörű fejlesztői környezetet ad a kezünkbe. 
A Nokia fejlesztői weboldaláról [4] letölthetők a cég telefonjai- 
nak Java alapú emulátorai és a hozzá tartozó fejlesztői környe- 
zet is, de ezek inkább csak utólagos nézegetéshez jók, mert - 
hogy is fogalmazzam finoman - kicsit instabilak. 


Tartalomtípusok 

A legfontosabb talán az, hogy az IIS-t meg kell tanítanunk a 
WML-es tartalomtípusok kezelésére. Hiába van ugyanis a WML 
tartalom már a kiszolgálón, az első wapos próbálkozás érdekes, 
eddig valószínűleg ritkán látott hibaüzenettel válaszol: 


HTTP Error 4DOL - Not acceptable 


A böngésző ugyanis (esetünkben a telefon) minden kérésben 
meghatározza az általa kezelni képes tartalomtípusokat (mint 
például: text/vnd.wap.wml). Ez a hibaüzenet akkor keletkezik, 
ha a kérés alapján a kiszolgáló biztos benne, hogy nem képes az 
ügyfél számára emészthető tartalomtípust produkálni - például 
mert egyiket sem ismeri. A wapos környezetben legelterjedtebb 
tartalomtípusok a következők: 

Kit. MIME típus Leírás 


.wml —— text/vnd.wap.wml WML kód 





WBMP képformátum 
WAML script kód 


.wbmp . image/vnd.wap.wbmp 
.wmls — text/vnd.wap.wmlscript 





.wmlc application/vnd.wap.wmlc WML bájtkód 





.wmlsc . application/vnd.wap.wmlscriptc . WMLScript bájtkód 
5 Az elterjedtebb WAP-os tartalomtípusok 


A táblázat utolsó két sorában a bájtkódra előre lefordított WML 
és WMLScript oldalak MIME típusa található, ezeket nem szük- 
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séges feltétlenül felvennünk, hacsak nem használjuk. A többit 
viszont igen: válasszuk ki a kiszolgálón a kívánt mappát, majd 
a tulajdonságlap HTTP Headers oldalán kattintsunk a File Types 
gombra, és sorra vegyük fel a fenti tartalomtípusokat. 
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0 WML tartalomtípusok az IIS-ben 


A kiterjesztésekkel a webkiszolgálónak segítünk, de majd látni fog- 
juk, hogy egy-egy tartalomtípust nemcsak a kiterjesztés alapján, 
hanem - természetesen - ASP-ből is beállíthatunk, így nem lesz 
gond, ha a mobiltelefon épp egy .asp oldalt próbál megnyitni. 


Az első lépések 

Kezdjük a munkát először egy statikus oldallal. Ha az menni fog, 
már bátran próbálkozhatunk a dinamikus működéssel. Lássunk 
egy Helló Világ példát! (A példaprogramok - szokás szerint — le- 
tölthetők az [1] címről.) 


£x?xml version-z"1.0" encoding-"iso-8859-2"?2 
LIDOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 
$ 1.2//EN" "http://www.wapforum.org/ 

$  DTD/wmlől.1.xml"2 


cXwml2 j 

£Kcard id-"cardl" title-"WML teszt"? 
£p aligns"center"2Helló Világ!C/p2 

£/card2 

£/wmi2 


Mentsük el a fenti kódot mondjuk index.wml néven. (Ha kell, ne fe- 
lejtsük el átállítani a könyvtárak alapértelmezett dokumentumát erre, 
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különben csak a közvetlen hivatkozások fogják megtalál- 
ni az oldalakat!) . Ha valami ilyesmit látunk, a beállítá- 
sok sikerültek. Ha nem, ak- 
kor ellenőrizzük, milyet hibát 
jelez a toolkit (szintaxishiba esetén 
nyilván a kódot, adattípus-probléma ese- 
tén pedig az IIS beállításait nézzük át). 
A dolog persze akkor igazán élvezetes, ha az ember rögtön iga- 
zi telefonról, élesben is kipróbálja. Ilyenkor érdemes indítani 
egy Network Monitort, és figyelni a kiszolgáló forgalmát. 


Ete] 


6] VAL teszt 
Helló Vílág! 


A kommunikáció 
A kiszolgálóhoz érkező kérés egy valós próbálkozás esetén a kö- 
vetkező volt: 


GET /wml/ HTTP/1.l 


Accept: application/vnd.wap.wmlc 

Accept: application/vnd.wap.wmlscriptc 
Accept: image/vnd.wap.wbmp 

Accept: application/vnd.wap.wtls-ca-cert 
Accept: image/gif 

Accept: text/plain 

Accept: application/x-NokiaGameData 
Accept: text/vnd.wap.wml 

Accept: text/vnd.wap.wmlscript 


Accept-Charset: IS0-8859-1 
Accept-Charset: UTF-8;g-0D.8 
Accept-Charset: IS0-L10LuLh-UCS-2;g-0.b 
Accept-Language: hu 

Host: localhost 

User-Agent: Nokia3330/1.0 (04.30) 
Via: WAP 1.2 222.52.12b.2:9202 
Pragma: no-cache 


A kérésből látható, hogy a böngésző tisztességesen be is mutat- 
kozik (User-Agent sor, esetünkben egy Nokia 3330). Ennek ké- 
sőbb még lesz jelentősége, ez az információ ugyanis bekerül a 
Reguest objektum ServerVariables kollekciójába, és segítségével 
nagyszerűen szét lehet majd válogatni a valódi böngészőktől il- 
letve a mobil készülékekről érkező kéréseket. A Via: fejlécben a 
wap gateway típusa (itt még az IP címe és a használt port is) 
látható. Érdemes még megfigyelni a feldolgozható MIME típuso- 
kat (Accept: fejlécek; érdekességképpen megemlíteném pl. az 
image/gif típust!) , illetve az elfogadott karaktertáblák (Accept- 
Charset:) listáját is. A tapasztalat azt mutatja, hogy bár a tele- 
fon nem jelzi, hogy képes lenne a közép-európai (IS0O-8859-2) 
kódtábla kezelésére, általában nincs gondja vele. Ha ez mégsem 
menne, tisztább és egyszerűbb rögtön UTF-8 kódolással dolgoz- 
ni. A kiszolgálótól érkező válaszban tulajdonképpen semmi kü- 
lönös nincs, egyetlen dolgot leszámítva: a Content-Type fejléc 
a szabályos WML tartalomtípust jelzi: 


Content-Type: text/vnd.wap.wml 


Képek előkészítése 

A WML-ben általánosan használható speciális képformátum, a 
.wbmp előállításához többféleképpen is nekifoghatunk. A wapos 
fejlesztői csomagok többsége tartalmazza a megfelelő képkon- 
vertáló eszközöket (vagy akár Interneten keresztül is konvertál- 
hatunk), de a [3] címről letölthető egy ingyenes plug-in, amely 
Photoshop illetve Paint Shop Pro bővítményként funkcionál. A 
komponens leírás szerinti telepítése után a kívánt képet egysze- 
rűen csak el kell mentenünk .wbmp formátumban. 
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5 Működésben a .wbmp plug-in 


Ügyeljünk arra, hogy bár a program képes gyakorlatilag tetsző- 
leges méretű képek mentésére, a készülékek korlátozott képes- 
ségeit is figyelembe kell vennünk. Az egyik határ a képek bájt- 
mérete: a legtöbb jelenleg elterjedt telefon legfeljebb 1.3 kilo- 
bájt méretű képeket kezel. A másik korlátozás pedig a képek 
mérete (képpontban), ezt nyilván a telefonok kijelzőjének fel- 
bontása korlátozza. A Nokia fejlesztői fórumának weboldaláról 
[4] letölthető dokumentációk alapján a nálunk ismertebb Nokia 
készülékek alapján ezek az értékek az alábbiak (természetesen 
ezek az információk megtalálhatók más gyártók készülékeihez is): 


Típus Képernyő Maximális képméret Maximális bájtméret 








3330 84x48 78x30 2,8kB 
5510 84x48 78x30 2,8kB 
6210 96x60 96x... 1,3kB 
6510 96x65 92x45 2,8kB 


5 Néhány elterjedt Nokia telefon karakterisztikája 


A legtöbb készülék képes a grafika görgetésére (legalábbis kép- 
nézegető üzemmódban, bár lehetséges, hogy csak függőleges 
irányba), ezért ami igazán korlátozza a lehetőségeinket, az a 
kép szélessége (általában nem érdemes 70 képpontnál szélesebb 
grafikával próbálkozni), valamint a bájtméret. Ha elkészültünk, 
a kész .wbmp állományt tegyük fel a webkiszolgálóra, majd 
gyártsunk hozzá egy WML fájlt is: 


£X?xml version-"1.0" encoding-"iso-8859-2"?2 
LIDOCTYPE wml PUBLIC "-//UWAPFORUM//DTD WML 
B 1.2//EN" "http://www.wapforum.org/ 

W  DTD/wmlől.l.xml"5 


cwmi2 
card id-"cardl" title-"WBMP teszt"? 
£Kp align-"center"2 
£Kximg src-"shrek.wbmp" alt-"Shrek"/2 
£/p2 
€/card2 
£/wm1i2 


Jöhet az ASP! 

Ha a natív WML fájlok kiszolgálása már nem okoz gondot, el- 
kezdhetjük a dinamikus oldalak készítését. Az ASP oldalakat fel- 
dolgozó motor - ha ezzel ellentétes utasítást nem kap -, tarta- 
lomtípusként a text/html-t állítja be, amit a wapos ügyfél ter- 
mészetesen nem képes feldolgozni. Ezért mindig első dolgunk 
legyen a megfelelő tartalomtípus beállítása (default.asp): 


ez. ÜS. 


Sz 
Response.ContentType - 
42 


"text/vnd.wap.wml" 


£€?xml versionzc"1.0" encoding-"iso-8859-2"?2 
SLIDOCTYPE wml PUBLIC "-//WUAPFORUM//DTD WML 
$.1.2//EN" "http://www.wapforum.org/ 

$ DTD/wml 1.1.xml"2 


cwmi2 

£Xcard id-"cardl" title-"ASP teszt"? 
XKp alignz"center"2£47-Now( )42c/p2 

£/card2 

€/wmi2 


Ha ezzel megvagyunk, nagy baj már nem lehet. Nyissuk meg az 
oldalt, próbáljuk ki, mi történik: ha minden jól ment, a telefon 
képernyőjén megjelenik az oldal lekérésének időpontja (köszön- 
hetően a kódban található c99-Now()9o2 sornak). 

Ha megnézzük a kiszolgáló által adott válasz fejléceit, láthat- 
juk, hogy abban szerepel egy, az alábbihoz hasonló sor: 


Set-Cookie: ASPSESSIONIDGARERGEZC- 
S JJINAFJAKOHKICFFGIMACDCK; path-/ 


A kiszolgáló tehát sütivel bombázza a telefonunkat. Az ASPSES- 
SIONIDxxxxxxxx nevű cookie egyébként - ha emlékszünk még - 
arra jó, hogy a kiszolgáló felismerhesse az azonos munkamene- 
ten belül feldolgozandó kéréseket. Ennek köszönhető többek kö- 
zött, hogy az ASP kódban használhatjuk a Session objektumot, 
mint tárolót. Sok telefon azonban ma még nem kezeli a cookie- 
kat, így ebben a tekintetben bizony vissza kell mennünk az első- 
második generációs böngészők szintjére. Ha ez így van, sajnos 
nagy az esély rá, hogy az ASP Sessionállapotok kezeléséről is le 
kell majd mondanunk. Ha viszont nem használjuk, a munkame- 
netek kezelését akár le is tilthatjuk, ezzel egyrészt megszüntet- 
jük az automatikus cookie-küldést, másrészt pedig biztosítjuk, 
hogy még véletlenül sem csábulunk el programozás közben :-) 






































5 A munkamanetek kezelése ASP alkalmazásonként letiltható 
A cookie-t nem támogató böngészőkhoz létezett egyébként megol- 
dás régebben: egy telepíthető ISAPI filter minden kimenő oldalt el- 
lenőrzött, majd a cookie-ba nem rakható információt utólag csatol- 
ta az oldalban található hivatkozások (URL-ek) végére. A bejövő ké- 
résekben pedig ugyanezeket felismerte, és így létrejöhetett a mun- 
kamenet. A probléma ezzel a megoldással az, hogy az URL-ek bőví- 
tése meglehetősen megnöveli a kód méretét (hiszen minden egyes 
hivatkozás végére odakerülne a cookie-k összes adata), amit a WML 
amúgy is szűkös keretei miatt nem engedhetünk meg magunknak. 
Kénytelenek vagyunk tehát más, állapotfüggetlen megoldást talál- 
ni. (Vagy várunk egy kicsit, míg elterjednek az , okosabb" telefonok: 
Nokia 3330 például már kezeli a munkamenet-cookie-kat) . 
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Ki kopog? 

Sok wapos szolgáltatás ugyanazon a címen érhető el 
mobiltelefonon, mint hagyományos böngészőn ke- 

resztül. Ilyenkor a kiszolgáló válogatja szét és irányítja 

az ügyfeleket a megfelelő tartalomtípushoz, és ehhez a ké- 
résbe kódolt információkat használja fel. 

A legkézenfekvőbb mód a böngésző típusának felismerése lenne, 
ha már olyan szépen bemutatkoznak, például (de lásd még: [5]): 





Nokiab21D/1.04(05.02) 
Nokia3330/1.04(04.30) 
Alcatel-BE4/2.0$UP/4.1.17e 
EricssonR320/RLA 
EricssonT31/R20L 
Mozilla/1.22 (compatible; 
9 Sony CMD-Z5) 


MMEF2O; Cellphone; 


A biztos azonosításhoz ez akár kevés is lehet (lásd az utolsó ké- 
szüléket, ami megtévesztő módon Mozilla-ként jelentkezik be). Ez 
azért nem meglepő, mert azon az adott telefonon bizony a Mic- 
rosoft Mobile Explorer fut. A böngésző típusának (azaz a 
Reguest. ServerVariables ("HTTP USER AGENT") értékének) vizs- 
gálata mellett, vagy inkább előtt jobban tesszük, ha annak né- 
zünk utána, hogy a böngésző képes-e kezelni a WML formátu- 
mot. Ehhez a HTTP. ACCEPT fejlécek között keressünk például a 
4nd.wap.wml"-re (példa később). Ha ezt megtaláltuk, biztosak 
lehetünk abban, hogy a kérés wapra vonatkozik. Ha nem, még 
mindig ellenőrizhetjük a HTTP USER AGENT string első néhány 
karakterét, és az alapján dönthetünk, mit adunk válaszként. A 
detect.asp példakód a fenti két trükk segítségével azonosítja a 
böngészőt, és emészthető választ ad vissza (WAP-os kérésre 
WML-t, hagyományos kérésre pedig HTML-t) . 


Átirányítás 

A HTTP protokoll támogatásának köszönhetően wapon keresztül 
is működik a böngésző átirányítása, tehát bátran használhatjuk 
a Response.Redirect() metódust is. Nincs más dolgunk, mint az 
alapértelmezett ASP oldal elejébe beilleszteni az alábbi kódot - 
ami felismeri a WML-t kezelni képes böngészőket - plusz egy 
átirányítást: 


sAccept - 
S LCase(Reguest . ServerVariables ( "HTTP. ACCEPT" ) ) 


If InStr( sAccept, "vnd.wap.wml" ) 2 0 Then 
Response.Redirect "wmlindex.asp" 
End If 


Felhasználóazonosítás 

A , névtelen" böngészés mellett a wapos telefonok támogatják a 
HTTP Basic (azaz nyílt jelszavas) felhasználóazonosítást is. Vi- 
gyázzunk, mert ez a protokoll nem titkosított, azaz elkapott há- 
lózati forgalomból könnyen visszafejthető a felhasználó neve és 
jelszava. A titkosított  wapos kommunikációt a wap szabványcsa- 
lád további elemei (pl. a WTLS) definiálják. 
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secret.wml Properties 


(File ] File Secutty (HTTP Headers [/ Custom Errors! 
Anonymous access and authenticalion control 


Enable anonymous access and edit the 
authentication methods for this resource. 











Authentication Methods 
CI Anonymous access 
No user name/password reguired to access this resource. 
Account used for anonymous acce: 

aHT 




















Alllow IIS 10 control password 
Server Certificate. 
Authenticaled access 

For the following authentication methods, user name and password 
are teguited when 


Vievi Cedilicate. 


access is disabled, or 28 


- öccess ís restticted using NTFS access control fsts. 





Digest suthentication for domain servers 


[ed Basic aehontásation (password is sent ín ciaér tant) 
Defaut domain 














Realm 











CO integrated Windoves authentication 














OK Cancel 





5 A névtelen wapos böngészés letiltható, a wapos készülékek 
pedig támogatják a nyíltjelszavas felhasználóazonosítást 


A felhasználóazonosítás bekapcsolásának legegyszerűbb módja, 
ha magán a webkiszolgálón beállítjuk azt. A fenti ábrán egy fájl 
tulajdonságlapján kapcsoltuk ki a névtelen kérések kiszolgálá- 
sát, de ugyanezt teljes könyvtárakon is megtehetjük. A másik 
módszer ASP-ből adódik: rögtön az oldal elején ellenőrizhetjük, 
hogy az AUTH USER HTTP változó tartalmazza-e a felhasználó- 
nevet. Ha nem, akkor pedig az oldal helyett visszaküldhetjük a 
szokásos, bejelentkezést előíró hibaüzenetet, valahogy így: 


If Reguest.ServerVariables( "AUTH USER") - "" Then 
Response.Status - "40Ol Unauthorized" 
Response.End 

End If 


Ha a telefon ilyen kéréssel találkozik, a felhasználónevet és jel- 
szót bekéri a felhasználótól: 


5 Bejelentkezés 


Egy egyszerű példa: a Service Manager 

A cikk végére egy rövid, de velős példát hagytunk: a Windows 
rendszerszolgáltatásainak távoli indítását és leállítását biztosító 
kis példaprogramot (a kód az [1] címen, az /svc alkönyvtárban ta- 
lálható). A rendszerszolgáltatásokhoz a WMI-nek köszönhetően 
férhetünk hozzá. Először is, - ha megfelelő jogosultságokkal ren- 
delkezünk - lekérhetjük az összes létező - vagy épp egy adott ne- 
vű - rendszerszolgáltatást jelképező WMI objektumok listáját: 
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Set oServiceSet - 

B GetObject( "winmgmts:( impersonationLevel- 

S  impersonate) ") .Execduery( "select t from 

b Win32 Service uUhere Name — "" 8. sName a """) 


Az eredmény egy enumerálható kollekció, aminek az elemei WMI 
Win32 Service objektumok: 


For Each oService In oServiceSet 
Response.Write oService.Name 8 "Cbr/2" 
Response.Write oService.State 8 "Cbr/2" 
Response.Write oService.Description 8 "Cbr/2" 

Next 


A Win32. Service objektum jellemzőiből kiolvasható a szolgálta- 
tás neve, leírása, és pillanatnyi állapota is. Ezeket az adatokat 
mi is felhasználjuk - és még két fontos metódust: 


nRet - oService.StopService() 
nRet - oService.StartService() 


A metódusok neve önmagáért beszél. A visszatérési érték 0, ha 
minden rendben ment, ellenkező esetben a művelet végrehajtá- 
sa során valamilyen hiba történt. 


f Service Manager — ager — Ez 
j írja be a szolgáltatás Válassza ki a kívánt 9 Themes (Running) 
reyjáátói kezdőbetűit: ! olgáltatást: Í íj 


0 Trkiwks (Stopped) / 
0 Tapisrv (Running) / 


(Select 7 Back 


a 


Service: Tintővr 
(stopped) ) 


Enables a remote user / 
[to log on to this Í 











o Service Manager wapon - a szolgáltatások indítása vagy 
leállítása egyetlen , kattintás" 


A példaprogramok további sorai ezeken kívül nem tartalmaznak 
semmi meglepő, új dolgot. 

Fülöp Miklós 

mick Onetacademia.net 


[SL TISZA ALAN AET TA 


[1] http://technet.netacademia.net/feladatok/asp/wml/ 
[21 http://developer.openwave.com 

[3] http://www.rcp.co.uk/downloads wbmp.htm 

[4] http://www.forum.nokia.com/ 

[5] http://webcab.de/wapua.htm 
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.NET kalauz: 
tanuljunk .NET-et! 
De hogyan? 


Aki nekilát .NET-et tanulni gyakran úgy érzi mag 


át, mint egy dzsungelharcos: vágja 


maga előtt a bozótot, küzd nagyon, de valójában fogalma sincs merre tart. 


Ez a kis útmutató azoknak nyújt segítséget, akik 
előnyeit, és minél gyorsabban használható tudás 


Ebben a cikkben a Microsoft hivatalos tanfolyami anyagainak 
(MOC) tükrében tekintem át a leendő .NET fejlesztők előtt álló 
utat. A cég iszonyatos tankönyvválasztékkal lepte meg a fejlesz- 
tői társadalmat, mely talán azt sugallja, hogy a .NET megtanu- 
lása nem webkattintgatós feladat, hanem elmélyült felkészülést 
kíván. Ha valaki az önálló tanulás híve, látogasson el a 
http://msdn.microsoft.com címre. Ha a tanfolyami formát ré- 
szesíti előnyben, már ma is több oktatóközpont kínálatában 
megtalálja a .NET-es tanfolyamokat. 

A 6-7 kötetnyi, egyenként 4-500 oldalas könyvek láttán az em- 
berben felmerül a csöndes visszavonulás stratégiája, ám ha 
mégis bátortalanul be- 

lekezd a .NET felfedezé- 

sébe, többé nem fog 

visszafordulni. Eldobja 


korábbi fejlesztési esz- ci 
közeit és elveit, hogy I 
valami csodálatos új 2124 
dolog rabja lehessen. CH 
A legfontosabb előzetes EKSÁT EAN ekette 
alapok 


tudnivaló a leendő fej- 
lesztőknek, hogy a .NET 
megtanulásában nem az 
új nyelvek elsajátítása 
lesz a legnagyobb falat, 


2524 
XML Webszolgáltatások 
írása Ctt nyelven 


Bev 


hanem a .NET keret- 

rendszer megismerése. A 2349 
legelemibb műveleteket A .NET keretrendszer 
(fájlműveletek,  bemene- programozása 
tek-kimenetek kezelése, C8 nyelven 
hálózati kapcsolatok ke- 

zelése,  adatbáziselérés, 

stb.) is másképp kell a á865 


.NET-ben megvalósítani, 
hisz kapunk egy elválasz- 
tó réteget az operációs 
rendszer szolgáltatásai 
és a saját programjaink 
közé. Adnak egy objektumorientált programozói felületet (.VET Class 
Library) , és szinte mindent ezen keresztül fogunk elérni. 

Emellett a .NET-es programoknak együtt kell működni a korábbi 
komponensekkel is (DLL-ek és COM komponensek) , ami további (nem 
triviális) programozási- és rendszerismereteket fog feltételezni. Ezek 
mellett az új nyelvek egyáltalán nem lesznek nehezek. 


Adatbázisalapú .NET 


ADO.NET-el 


working with windo 









programozásba 


alkalmazások fejlesztése 


szeretnék élvezni a .NET fejlesztések 
ra szeretnének szert tenni. 


Az átlényegülés előrehaladottabb fázisában járó programozók 
azt mondják, hogy a .NET tanulásában 909-nyi idő a keretrend- 
szerre, további 1099 pedig az új nyelvekre megy el. 
A .NET alapjaiban objektumorientált elvekre épült, így nagyon hasz- 
nos az objektumorientált alapelvek megfelelő ismerete. A vaskos 
könyvek objektumorientált elmélettel is szolgálnak. Aki ezeket isme- 
ri, máris 200 oldallal előrébb lapozhat. 
Kezdjük az alapokkal: a .NET-es nyelvek 
Elméletileg sok, gyakorlatilag kétféle nyelv érdekes a legtöbb 
.NET programozó számára: a Ctt (ejtsd: szí sárp) és a Visual Ba- 
sic.NET. Aki szereti a C jellegű kapcsos zárójeles ( (7 ) nyelve- 
ket, és szeretné a Mic- 
START) rosoft által is favorizált 
"8il nyelven programozni a 
.NET-et, annak a CH-ot 


Cít vagy VENET ajánlom. Nem olyan bo- 
VB:NET? l nyolult, mint a Csik, 
2373 nincsenek benne a so- 
VB.NET kak számára érthetetlen 
gets] pointerek, inkább VB-re 

alapok 


emlékeztet vele a prog- 
ramozás, csak C-s for- 
mátumban. Aki a JAVA-t 
ismeri, annak különö- 
sen könnyű lesz a nyelv 





2063 
ezetés az ASP.NET 


elsajátítása. 
2415 
A .NET keretrendszer Ctt programozási ala- 
programozása pok 
KEEN NgeNen (2124 - Introduction to 
C$ Programming for the 
Microsoft .NET Platform) 
Aki szeretné mélységei- 
2350 


ben megismerni a nyel- 
vet, és felfrissíteni az ob- 
jektumorientált  progra- 
mozási ismereteit, annak 
a 2124-es , Introduction 
to CH Programming for the Microsoft .NET Platform" tanfolyam 
ajánlható. Ez egy kőkemény alapozó tanfolyam, amely a , Helló vi- 


:NET komponensek 
biztonságtechnikája és 
terjesztése 


mélyen belemegy a Ct nyelv fejlett lehetőségeibe is. Eközben elka- 
lauzolja a hallgatót az objektumorientált elvek Ct-beli alkalmazásá- 
ba, megtanítja néhány Design Pattern alkalmazását, s közben össze- 
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De hogyan? 


.NET-et! 


tanuljunk 


.NET kalauz: 


A programozók az idejük 
java részében a 
keretrendszer 
szolgáltatásait veszik 
igénybe egy-egy funkció 
megvalósításakor. 

Ez a .NET lelke. 
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tett, de jól előkészített és a tanfolyamon tanult elmé- 
lettel szinkronban haladó laborgyakorlatokkal segít el- 
sajátítani a bőséges elméleti ismereteket. A tanfolyam 
nagy előnye, hogy ahelyett, hogy szárazon bemutatná a 
nyelv elemeit, inkább sok példával és nagyon sok programozá- 

si stílust javító tanáccsal látja el a hallgatókat. 


A .NET keretrendszer programozása Ctt nyelven 

(2349 - Programming Microsoft .NET Framework with Microsoft 
Visual C$) 7 

Aki már akár saját maga, akár a 2124-es tanfolyam segítségével 
túljutott a Ctt, mint programozási nyelv alapjain, megértette 
azokat az objektumos és komponensalapú fejlesztési elveket, 
amelyek a Ctt magját alkotják, akkor jöhet a nagyobb falat, a 
.NET keretrendszer (.NET Framework), illetve ezen belül a .NET Class 
Library (osztálykönyvtár) megismerése. 

Ez a tananyag a keretrendszerről szól. A programozók az idejük 
java részében a keretrendszer szolgáltatásait veszik igénybe 
egy-egy funkció megvalósításakor. Ez a .NET lelke. Kihasználá- 
sához és eléréséhez jelentős segítséget és fejlesztési sebességet 
ad a Visual Studio.NET, de a keretrendszer ismerete nélkül csak 
kövérre hízott kódvarázslóként fogyasztja a merevlemezünket. 
A kurzus áttekinti a menedzselt futtató környezet működését, és 
.NET komponensek fejlesztésének kérdéseit. A .NET egyik leg- 
fontosabb sarokköve a Common Type System, amely az összes 
.NET-es nyelv alaptípusait definiálja. Ezzel fontossága miatt 
több fejezet is foglalkozik. Kiderül a leggyakrabban használt 
alaptípus, a String sok fontos funkciója, és megismerjük a töm- 
bök és kollekciók fajtáit és használatát. 

Az egyik gyakran használt és nagyon sok programozási munkát 
megtakarító fogalom, a delegate (függvénymutató) használata, 
ehhez kapcsolódik a .NET natív eseménykezelésének megismerése. 
Az egyik legtöbb félreértést és jövőbeli problémát okozó témakör, 
a memóriakezelés és a nem determinisztikus memóriafelszabadítás 
külön fejezetet kapott. A fájlkezelés és Internetes erőforrások ke- 
zelése külön-külön részben van kifejtve, hisz a leggyakrabban 
használt programozási alapfogásokról van szó. A Serialization, ob- 
jektumok állapotának futásidejű elmentése és visszaállítása egy 
igen lényeges alaptechnológia a .NET-ben, emiatt egy komplett 
fejezetet dedikálunk neki. Ha .NET, akkor a WebSzervizek témája 
kikerülhetetlen (nem mintha annyira égető lenne a téma Magyaror- 
szágon, de előbb-utóbb ide is 
elér a szele) , így az utolsó fe- 
jezet ezt taglalja. Megismer- 
kedünk a technológia hát- 
terével és programozási fogá- 
saival. Ugyanez a fejezet 
foglakozik a DCOM utódjával, 
a .NET Remoting-al, ami az 
egyik legokosabban megvaló- 
sított, és nagyon sűrűn hasz- 
nált szolgáltatása lesz a ke- 
retrendszernek. 

Látható, hogy nagyon nagy anyagrészekkel ismertet meg ez a tanfo- 
lyam, amelyen elindulva már el lehet kezdeni a fejlesztési és terve- 
zési munkákat. A .NET keretrendszer akkora falat, amit szinte lehe- 
tetlen teljes egészében feldolgozni akár tanfolyami keretek között, 
akár önállóan. Ez a tanfolyam viszont alkalmas olyan alap átadására, 
amelyen elindulva már képesek a hallgatók a további részletek és 
újabb témakörök önálló elsajátítására. Mondjuk úgy, hogy megtanít 
.NET-ül gondolkodni, szemléletet ad a további fejlődéshez. 


vörkingy vithbh 


windows / 


VB.NET programozási alapok 

(2373 - Programming with Microsoft Visual Basic .NET) 

A VB.NET kezdő tanfolyam nem annyira a kezdetektől indul, 
mint Ct-os párja, lévén hogy nem egy teljesen új nyelvről van 
szó. A jelenleg VB6-ban programozóknak segít megtanulni a 
nyelv új elemeit, illetve átadja a hozzátartozó új szemléletet. 
Pont a már meglevő alapok miatt a kurzusnak csak kb. a fele fog- 
lalkozik magával a VB.NET nyelvvel, a többi rész inkább megmu- 
tatja, hogy a VB-ben már ismert eszközöket és technológiákat ho- 
gyan kell használni VB.NET-ben illetve a Visual Studio.NET alatt. 
A .NET keretrendszer és a Visual Studio.NET alapjainak megismerése 
után jönnek az új nyelvi elemek: adattípusok, tömbök, függvények 
és strukturált hiba- 
kezelés (try-catch-fi- 
nally, halál az On 
Enor-ra :). 

Mivel az objektum- 
orientált elvek 
megjelenése új a 
VB.NET-ben, ezért 
erre a tanfolyam 
külön — hangsúlyt 
helyez. Az objek- 
tumorientált  alap- 
fogalmakkal (egy- 
ségbezárás, öröklődés, interfészek és polimorfizmus) példákon ke- 
resztül ismerkedünk meg, és megnézzük egy konkrét tervezési pél- 
dán keresztül, hogy a valós objektumokat hogyan lehet programo- 
zott objektumokkal modellezni elméletben, és a Visio segítségével 
számítógépen is. Ezt követően átültetjük az elméletet a gyakorlat- 
ba, és a VB.NET konstrukciói segítségével létrehozzuk az objektu- 


Az egyik legtöbb 
félreértést és jövőbeli 
problémát okozó 
témakör, a 
memóriakezelés és a 
nem determinisztikus 
memóriafelszabadítás 
külön fejezetet kapott. 


A VB6 Form technológia nagyon könnyen használható keret- 
rendszert adott ablakokra épülő alkalmazások írásához. Átte- 
kintjük mit kínál ezen a téren a .NET Windows Forms technoló- 
gia, amely hasonlóan egyszerűen használható, ám jóval kifino- 
multabb és átgondoltabb VB-beli öccsénél. 

ASP.NET-es webalkalmazásokat bármely .NET-es nyelven lehet 
írni, ezért megnézzük, hogy hogyan épülnek fel a .NET-es webal- 
kalmazások és Webszervizek. Erről a témáról bővebben a 2063 
s Introduction to ASP.NET" értekezik. 

Az új adatelérő komponenskészlet, az ADO.NET az egyik leg- 
gyakrabban alkalmazott járulékos .NET technológia, így - egy 
fejezet erejéig - megismerkedünk az alapokkal. 

Az újrafelhasználható komponensek témaköre a .NET assem- 
blykel, a saját felhasználói felület elemekkel (Windows Forms 
Controls) és ASP.NET webformokkal foglalkozik. 

Legtöbb cégnél az egyik legnagyobb fejtörést okozó probléma 
az elkészült alkalmazások tömeges telepítése szokott lenni. A 
megoldáshoz sok segítséget nyújt a .NET alapjaiban átgondolt 
komponens (assembly) azonosítási és verziózási képessége. 
Fontos kérdés a VB6-2VB.NET upgrade. Mi változott, mi minek 
felel meg az új nyelvben? Látható, hogy ez a tanfolyam gyakor- 
latiasabb mint a Ct-os társa (2124), viszont nem építi fel olyan 
mélységig az alapokat. 


A .NET keretrendszer programozása VB.NET nyelven 

(2415 - Programming the Microsoft .NET Framework with Visual 
Basic .NET) 

Ez a tanfolyam gyakorlatilag ugyanarról szól, mint a .NET keret- 
rendszer programozása Ctt nyelven tanfolyam (2349-es), csak 
VB.NET nyelvre kihegyezve. A tartalmát lásd a Ct-os társánál. 


e008. US. 


.NET alapú programfejlesztés 

A nyelvek és a keretrendszer ismeretében már megvan a .NET-es 
programozó írási-olvasási képessége. Azonban a gyakorlati fej- 
lesztés során további problémákba fog botlani, amelyek fejlesz- 
tőnként és feladatonként más és más lesz. 

Az egyik leggyakoribb és legégetőbb kérdés az adatbázisok hasz- 
nálatának kérdése a .NET-es programokból. Akiknek ez a felada- 
ta (a fejlesztők jelentős része) , azoknak a 2389 - Developing App- 
lications Using ADO.NET for Microsoft SOL Server 2000 (3 napos) 
tanfolyam nyújt segítséget. 

Az elkészült alkalmazások telepítése és biztonságtechnikája a 
.NET egyik legösszetettebb kérdése. Ebben a 2350 - Securing and 
Deploying Microsoft .NET Assemblies tanfolyam nyújt útmutatást 
az érdeklődőknek. A vírusok és egyéb ártalmak világában ez a té- 
makör kulcsfontosságú lesz a biztonságos programok írásához. 
A  webalkalmazás-prog- 
ramozók számára az 
ASP.NET új, igen haté- 
kony eszközöket kínál, 
melyek kiaknázásához a 
2063 - Introduction to 
Microsoft ASP.NET tanfolyam szolgál kiindulópontul. 

Az első két kurzus feltételezi a .NET keretrendszer ismeretét, 
amelyet a választott nyelven a 2349 - Programming Microsoft 
.NET Framework with Microsoft Visual Ctt vagy a 2425 - 
Programming the Microsoft .NET Framework with Visual Basic 
.NET tanfolyamok tudnak nyújtani. 

Az ASP.NET tanfolyamhoz nem szükséges a keretrendszer átfogó 
ismerete, viszont valamelyik .NET-es nyelv (Cs vagy VB.NET) tudá- 
sa nagyban hozzájárul a tanfolyamon tanultak elsajátításához 
(2124 - Introduction to C$ Programming for the Microsoft .NET Plat- 
form vagy 2373 - Programming with Microsoft Visual Basic .NET) . 


Miért fog kihalni 
az ADO? 
Miért, ki fog halni? 


Adatbázisalapú .NET alkalmazások fejlesztése ADO.NET-tel 
(2389 - Developing Applications Using ADO.NET for Microsoft SOL 
Server 2000) 

Miért kellett már megint lecserélni az adatelérési komponense- 
ket? Miért fog kihalni az ADO? Miért, ki fog halni? Milyen prob- 
lémákkal nézett szembe az ADO, ami miatt ki kellett fejleszteni 
az ADO.NET-et? 

Ezen kérdések megválaszolása után rátérünk az ADO.NET-et al- 
kotó osztályok és névterek feltérképezéséhez. Megbeszéljük me- 
lyek azok a helyzetek, ahol folyamatos adatbáziskapcsolatra van 
szükségünk, és mikor használható a sokkal jobban skálázható 
lecsatolt (disconnected) adatkezelési modell. 

Megnézzük, melyek a leghatékonyabb módszerek SOL Server adat- 
bázisok, OLE-DB meghajtóval rendelkező adatbázisok és XML 
adatforrások adatainak elérésére. Áttekintjük a különböző jellegű 
adatbázislekérdezések leghatékonyabb végrehajtásának lehetősé- 
geit. Megtanuljuk, hogy az ADO beégetett adatmódosító rendszer 
tárolt eljárásai helyett hogyan írhatunk saját, optimalizált adat- 
módosító eljárásokat. Kitérünk olyan finomságokra, mint az SOL 
Server zárolások szabályozása. Megnézzük hogyan kell szaksze- 
rűen lekezelni az adatbázisműveletek során fellépő hibákat. 

Az ADO.NET egyik nagy újítása a típusos adathalmazok (Typed Data 
Sets) felépítésének lehetősége. Emellett bármikor láthatjuk a relá- 
ciós adatokat XML-ként, illetve fordítva, XML forrásokkal módosít- 
hatunk relációs adatbázisok tartalmát (nem csak SOL Servert). Ez a 
szoros integráció hatalmas lehetőségeket rejt magában. Megnézzük 
a DataSet, DataTable és DataView osztályok szerepét és működését. 
Felsorolásszerűen még néhány témakör a tananyagból: a 
DataSet mint ügyféloldali cache kihasználása lecsatolt architek- 
túrákban; adatelérés a DataAdapter osztály segítségével; a 





working with 


windows / 


Visual Studio .NET adatelérő varázslóinak használa- 

ta tárolt eljárások és típusos adathalmazok generá- 

lására. Hogyan hajtsunk végre XLANG (BizTalk) üte- 

mezett feladatokat ADO.NET-el? 

Miként működnek a lecsatolt adathalmazokon végzett módosí- 
tások, és miként lehet a változtatásokat visszamenteni az adat- 
bázisba? Fontos kérdés a módosítási konfliktusok kezelése is. 
Különösen nagyvállalati környezetben gyakori feladat adatbázison 
belüli, és adatbázisok közötti vagy teljesen heterogén rendszerek 
közötti tranzakciók létrehozása. Áttekintjük a lokális és az elosztott 
tranzakciók ADO.NET-féle végrehajtásának részleteit, és megnéz- 
zük, hogy a Message Oueue technológia milyen segítséget nyújthat 
a fokozott és ingadozó teljesítményigények kiegyenlítésére. 

Az utolsó részben megvitatjuk, hogy milyen feladatra melyik techno- 
lógiát érdemes használni a Webszerviz, Webform és Windows alkal- 
mazások közül? Írunk adatelérő Webszervizt, amely szolgáltatásait 
kihasználjuk webalkalmazásból és Windows Form alkalmazásból is. 


:NET komponensek biztonságtechnikája és terjesztése 
(2350 - Securing and Deploying Microsoft .NET Assemblies) 
Attól, hogy a fejlesztő fogai közül kihúzzák a program ,végső" 
verzióját, a felhasználók gépein még nem fog futni az alkalmazás. 
A szlogen: .NET-ben a telepítés nem más, mint fájlok másolása. 
Ez , szinte" így is van. És a konfiguráció, a verziókövetés, a kom- 
ponens megbízhatóságának ellenőrzése és a rendszer védelme a 
káros programoktól? Hová írogathat egy .NET-es program (pl. ví- 
rus)? És a közös komponensek kérdése? A valóság egy ,picit" 
összetettebb a másolásos telepítésnél, ezért ez a tanfolyam. 
Megnézzük mi az a DLL pokol, mi idézi elő és mit tehettünk a 
COM világban a megelőzése érdekében. Áttekintjük, hogy a .NET 
assemblyk hogyan próbálják gyökerestül kiirtani a probléma 
okait. Körüljárjuk az egy illetve több fájlból álló assemblyk lét- 
rehozásának igényét és kérdéseit. Megnézzük mire való a 
Reflection nevű technológia, hogyan érhetőek el az assembly 
metaadatok a segítségével. 

Megtekintjük a .NET-es biztonsági házirendek felépítését, hogyan 
kell egyedi és közös komponenseket telepíteni. Mélyen belemegyünk 
a verziókövetés kérdésébe, és megvilágítjuk a fokozatos letöltés 
(incremental download) technológia működését és használatát. 
Megtanuljuk, hogyan ellenőrzi a .NET futtató egy program által 
tervezett lépéseket, hogyan lehet digitálisan aláírni az as- 
sembly-ket és milyen előnyünk származik ebből. 

A .NET saját biztonsági réteget épített az operációs rendszerben 
meglévő védelem fölé. Ezt akár kódból is kihasználhatjuk (Code 
Access Security). Az 
Isolated Storage nevű 
biztonságos lemezterület 
felhasználási technoló- 
giával megelőzhetők a 
programok egymásra ha- 
tásai, a különböző alkal- 
mazások adatainak keveredése. Áttekintjük a használat módjait. 
A menedzselt .NET-es kódok és a nemmenedzselt COM vagy na- 
tív DLL kódok együttműködése igen érzékeny terület, amely a 
COM és a .NET együttélés miatt még sokáig aktuális téma lesz, 
megismerjük a használati lehetőségeket és buktatókat. 





másolása. 


Bevezetés az ASP.NET programozásába 

(2063 - Introduction to Microsoft ASP.NET) 

A .NET leghamarabb bizonyított és már Béta állapotban is ren- 
geteg website által is használt része. Tulajdonképpen ez az el- 
ső, a .NET keretrendszer szolgáltatásaira épülő - Microsoft által 
fejlesztett - alkalmazás. Az ASP.NET a programozók számára is 
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De hogyan? 


:NET-6t! 


tanuljunk 


.NET kalauz: 


ES 


hatalmas kényelmi lépést jelent, de emellett (ami 

sokszor még fontosabb) az újratervezett architektú- 

ra sokkal nagyobb megbízhatóságot kínál. 
A tanfolyam elején megnézzük milyen okok miatt kel- 

lett átalakítani az egyébként nagyon sikeres ASP modellt. 

Megismerjük a két alapvető kiszolgálóoldali vezérlőt: a HTML 
elemek programozhatóvá tett változatait: az intrinstic vezérlő- 
ket; valamint a magasabb funkcionalitású webvezérlőket. Ezek 
mindegyike olyan paraméterezhető HTML generátor, amely se- 
gítségével a VB6-ban megismert eseménykezelőkhöz hasonló 
megközelítésben és jellemzőkön keresztül tudjuk programozni a 
webes űrlapokat. Az ASP.NET igyekszik elfedni a webes progra- 
mozói világ és a formalapú alkalmazások gondolkodásmódjának 
különbségeit, így egy webprogramozás- 
ban nem jártas, de formalapú alkalmazá- 
sokban gyakorlott programozó a már szá- 
mára ismert elvek jelentős részét képes 
alkalmazni munkájában. 
Áttekintjük hogyan lehet deklaratív mó- 
don adatkapcsolatokat kijelölni vezérlők 
között (nemcsak adatbázishoz, hanem 
egymás között is). A felpostázandó formadatok ellenőrzésére ki- 
használjuk az adatellenőrző vezérlőket (validation controls). 
A dinamikus webalkalmazások háttéradatait leggyakrabban adat- 
bázisok tárolják, így azok elérését közelebbről is megnézzük az 
ADO.NET segítségével. Alkalmazzuk azokat a vezérlőket, amelyek 
közvetlenül képesek adatbázisadatok (sorok) megjelenítésére. 
Az ASP.NET lapok mögött nem interpretált, hanem lefordított kó- 
dok futnak, ami jelentős sebességnövekedést jelent az ASP-hez 
képest. Emellett a kódot teljes mértékben elválaszthatjuk a meg 
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jelenítést végző vezérlőktől, így könnyebben kézbentartható lapo- 
kat kapunk, és szétoszthatjuk a lapformátum kialakítási és a prog- 
ramozási munkáit. Ráadásul a forráskódot lefordíthatjuk bináris 
komponensekké, így a webszerveren nem kell forráskódot tárolni. 
A hibakeresés hírhedten problémás pontja volt az ASP alkalma- 
zásoknak, a beépített nyomkövetési funkcionalitás nagy segít- 
ség lesz a programozók számára. Az internetes alkalmazások 
együttműködésének egyik bástyája a Webszerviz technológia lesz. 
Megtanuljuk a Webszervizek írásának és tesztelésének módszereit. 
Az alapozás után az utolsó fejezet felvázolja azokat a fejlett 
ASP.NET lehetőségeket, amelyeket eddig mindig meg kellett írni 
az ASP lapokban, de most készen kapjuk: cookie nélküli állapotke- 
zelés, a global.asax új eseményei, kimeneti HTML gyorsítótár hasz- 
nálata, out-of-process és SOL adatbá- 
zisalapú állapotkezelés használata, form- 
és Microsoft passport alapú felhasználói 


sági konfigurálása. 


...És már túl is vagyunk a .NET alapjain. 
Jövő ilyenkor remélhetőleg sokan úgy 
tekintenek majd vissza erre a néhány oldalra, mint a megtett út 
térképére, és a kávéautomata mellett éppoly ügyesen dobálóz- 
nak majd a Reflection és Serialization fogalmakkal, mint manap- 
ság az Option Explicittel. Addigra egyesek szerint a Ctt nyelv is 
annyira mindennapivá válik, hogy megszűnik tanfolyami oktatá- 
sa, és áttérhetünk a .NET komolyabb felhasználására: jöhetnek 
a platformfüggetlen alkalmazások! 


Soczó Zsolt 
zsolt.soczo onetacademia.net 


http://vilagokorseg.hu 
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.NET Akadémia 


(II. rész) - . NET alaptípusok 


Az előző részben áttekintettük a .NET alapjait madártávlatból, valamint láttuk hogyan 

kell mezőket, metódusokat és jellemzőket definiálni egy osztályban. Ebben a részben 
megnézzük az osztályok további jellemzőit, körbejárjuk, hogy miért nagyon fontos az érték 
és referencia típusok megkülönböztetése. Menet közben érintjük a .NET egyik igen fontos 
sajátosságát, a nemdeterminisztikus objektum-életciklust is. 


Osztályok (folytatás) 

Jellemzők (propertyk) 

Láttuk, hogy a metódusok segítségével írhatunk ellenőrzött mező- 
beállító és -lekérdező megoldásokat, csak elég kényelmetlen az 
obj.Metódus(érték) formátum egy mező értékének beállítására. 
Mennyivel természetesebb a tiltott gyümölcs, a közvetlen mező- 
elérés: obj.Mező - érték. Mivel egyszerűbb formátuma miatt a kí- 
gyó csábítja a programozókat a közvetlen mezőelérésre, ezért a 
.NET-be alapjaiban beépítették azt a lehetőséget, hogy a mezők ér- 
tékét lekérdező és beállító metódusokat külön-külön megírhassuk, 
de kívülről úgy hivatkozzunk a metódus-párosra, mintha tagválto- 
zók lennének. Ezt nevezzük jellemzőnek vagy angolul property-nek. 
Nézzük csak! Klasszikus esetben írunk egy SetXXX(), GetXXX() elérő 
metóduspárt, és ezt használjuk a mezők értékének manipulálására: 


class JorgomBorger ( 
int a s 4; 


//Klasszikus megoldás metódusokkal 

public int GetA() ( return a; ) 

public void SetA(int a) ( this.a — a; ) 
:) 


Használatuk: 


JorgomBorger jb - new JorgomBorger ( ) ; 
int x - jb.GetA(); 
jb.SetA(93); 


Működik, de elég kényelmetlen. 

Jellemzők definiálásához is meg kell írni a set/get párost egy 
meghatározott formátumban, azonban a hivatkozás sokkal egy- 
szerűbb lesz. 


class JorgomBorger ( 
int a 54 
public int A 
( 
get ( return a; ) 
set 
t 
if (a5 0) 
a - value; 
else 
throw new ArgumentException( 
" A csak pozitiv lehet!"); 
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JorgomBorger jb - new JorgomBorger ( ); 
int x - jb.A; 
jb.A 5 9; 


A set-ben használt value Ci kulcsszó, a jellemzőnek átadott 
balértéket jelöli (pl. 9). Bármelyik kulcsszó elhagyásával írha- 
tunk csak olvasható vagy csak írható jellemzőt is. 

A jellemző beállításakor általában értékhatár-ellenőrzést is vég- 
zünk. A példában csak pozitív számokat fogadunk el, más szá- 
moknál egy kizárást (exception) hajtunk végre, amelyet a hívó 
metódusnak le kell kezelni. Erre még visszatérünk egy későbbi 
részben. Amit nagyon fontos látnunk, hogy a jellemzők kényel- 
mes lehetőséget biztosítanak a mezők ellenőrzött hozzáférésé- 
re, de a metódusok nehézkesebb hívási formátumát nélkülözve. 
Emellett a jellemzők mögött sokszor nem valódi tagváltozók áll- 
nak, hanem például valamilyen számított érték. Pont az a sze- 
repük, mint a metódusoknak: elfedni a fizikai megvalósítást, az 
osztály belső szerkezetét. 


Konstruktorok, destruktorok 

Minden osztálynak van legalább egy speciális metódusa, amit 
konstruktornak hívunk. Ha mi magunk nem hozunk létre, akkor 
is keletkezik egy, amit a fordító hoz létre nekünk. A konstruk- 
torok neve megegyezik az őket tartalmazó osztály nevével, 
nincs visszatérési értékük, de lehetnek paramétereik. Nézzünk 
bele a Kutyus osztályba: 


Class Kutyus í 
Kutyus() ( 52 
Kutyus(string szin) ( ...) 
4 


Neki mindjárt két konstruktora is van, az egyik nem vár paramé- 
tert, a másik igen, a kutya színét string típusban. 

A konstruktor egyszer hívódik meg, akkor, amikor létrejön az osz- 
tályból egy példány. Feladata az objektum belső kiinduló állapo- 
tának, például tagváltozók értékének beállítása induló értékre. 
Több változat esetén melyik konstruktor hívódik meg? Az a lét- 
rehozás módjától függ. A 


Kutyus k - new Kutyus( ); 
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hatalmas kényelmi lépést jelent, de emellett (ami 
sokszor még fontosabb) az újratervezett architektú- 

y 9 ra sokkal nagyobb megbízhatóságot kínál. 

. A tanfolyam elején megnézzük milyen okok miatt kel- 

lett átalakítani az egyébként nagyon sikeres ASP modellt. 
Megismerjük a két alapvető kiszolgálóoldali vezérlőt: a HTML 
elemek programozhatóvá tett változatait: az intrinstic vezérlő- 
ket; valamint a magasabb funkcionalitású webvezérlőket. Ezek 
mindegyike olyan paraméterezhető HTML generátor, amely se- 
gítségével a VB6-ban megismert eseménykezelőkhöz hasonló 
megközelítésben és jellemzőkön keresztül tudjuk programozni a 
webes űrlapokat. Az ASP.NET igyekszik elfedni a webes progra- 
mozói világ és a formalapú alkalmazások gondolkodásmódjának 
különbségeit, így egy webprogramozás- 
ban nem jártas, de formalapú alkalmazá- 
sokban gyakorlott programozó a már szá- 
mára ismert elvek jelentős részét képes 
alkalmazni munkájában. 
Áttekintjük hogyan lehet deklaratív mó- 
don adatkapcsolatokat kijelölni vezérlők 
között (nemcsak adatbázishoz, hanem 
egymás között is). A felpostázandó formadatok ellenőrzésére ki- 
használjuk az adatellenőrző vezérlőket (validation controls). 
A dinamikus webalkalmazások háttéradatait leggyakrabban adat- 
bázisok tárolják, így azok elérését közelebbről is megnézzük az 
ADO.NET segítségével. Alkalmazzuk azokat a vezérlőket, amelyek 
közvetlenül képesek adatbázisadatok (sorok) megjelenítésére. 
Az ASP.NET lapok mögött nem interpretált, hanem lefordított kó- 
dok futnak, ami jelentős sebességnövekedést jelent az ASP-hez 
képest. Emellett a kódot teljes mértékben elválaszthatjuk a meg 
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jelenítést végző vezérlőktől, így könnyebben kézbentartható lapo- 
kat kapunk, és szétoszthatjuk a lapformátum kialakítási és a prog- 
ramozási munkáit. Ráadásul a forráskódot lefordíthatjuk bináris 
komponensekké, így a webszerveren nem kell forráskódot tárolni. 
A hibakeresés hírhedten problémás pontja volt az ASP alkalma- 
zásoknak, a beépített nyomkövetési funkcionalitás nagy segít- 
ség lesz a programozók számára. Az internetes alkalmazások 
együttműködésének egyik bástyája a Webszerviz technológia lesz. 
Megtanuljuk a Webszervizek írásának és tesztelésének módszereit. 
Az alapozás után az utolsó fejezet felvázolja azokat a fejlett 
ASP.NET lehetőségeket, amelyeket eddig mindig meg kellett írni 
az ASP lapokban, de most készen kapjuk: cookie nélküli állapotke- 
zelés, a global.asax új eseményei, kimeneti HTML gyorsítótár hasz- 
nálata, out-of-process és SOL adatbá- 
zisalapú állapotkezelés használata, form- 
és Microsoft passport alapú felhasználói 


sági konfigurálása. 


...és már túl is vagyunk a .NET alapjain. 
Jövő ilyenkor remélhetőleg sokan úgy 
tekintenek majd vissza erre a néhány oldalra, mint a megtett út 
térképére, és a kávéautomata mellett éppoly ügyesen dobálóz- 
nak majd a Reflection és Serialization fogalmakkal, mint manap- 
ság az Option Explicittel. Addigra egyesek szerint a C$ nyelv is 
annyira mindennapivá válik, hogy megszűnik tanfolyami oktatá- 
sa, és áttérhetünk a .NET komolyabb felhasználására: jöhetnek 
a platformfüggetlen alkalmazások! 


Soczó Zsolt 
zsolt.soczo onetacademia.net 


http://vilagokorseg.hu 
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.NET Akadémia 
(II. rész) - . NET alaptípusok 


Az előző részben áttekintettük a .NET alapjait madártávlatból, valamint láttuk hogyan 

kell mezőket, metódusokat és jellemzőket definiálni egy osztályban. Ebben a részben 
megnézzük az osztályok további jellemzőit, körbejárjuk, hogy miért nagyon fontos az érték 
és referencia típusok megkülönböztetése. Menet közben érintjük a .NET egyik igen fontos 
sajátosságát, a nemdeterminisztikus objektum-életciklust is. 


Osztályok (folytatás) 

Jellemzők (propertyk) 

Láttuk, hogy a metódusok segítségével írhatunk ellenőrzött mező- 
beállító és -lekérdező megoldásokat, csak elég kényelmetlen az 
obj.Metódus(érték) formátum egy mező értékének beállítására. 
Mennyivel természetesebb a tiltott gyümölcs, a közvetlen mező- 
elérés: obj.Mező z- érték. Mivel egyszerűbb formátuma miatt a kí- 
gyó csábítja a programozókat a közvetlen mezőelérésre, ezért a 
.NET-be alapjaiban beépítették azt a lehetőséget, hogy a mezők ér- 
tékét lekérdező és beállító metódusokat külön-külön megírhassuk, 
de kívülről úgy hivatkozzunk a metódus-párosra, mintha tagválto- 
zók lennének. Ezt nevezzük jellemzőnek vagy angolul property-nek. 
Nézzük csak! Klasszikus esetben írunk egy SetXXX(), GetXXX() elérő 
metóduspárt, és ezt használjuk a mezők értékének manipulálására: 


class JorgomBorger ( 
int a z 4; 


//Klasszikus megoldás metódusokkal 

public int GetA() ( return a; ) 

public void SetA(int a) ( this.a — a; ) 
) 


Használatuk: 


JorgomBorger jb - new JorgomBorger ( ) ; 
int x 5 jb.GetA(); 
jb.SetA(9); 


Működik, de elég kényelmetlen. 

Jellemzők definiálásához is meg kell írni a set/get párost egy 
meghatározott formátumban, azonban a hivatkozás sokkal egy- 
szerűbb lesz. 


class JorgomBorger ( 
int a z 4; 
public int A 
í 
get ( return a; ) 
set 
( 
16 Wa 
a - value; 
else 
throw new ArgumentException( 
" A csak pozitiv lehet!"); 
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JorgomBorger jb - new JorgomBorger( ); 
int x - jb.A; 
jb.Asa ai 


A set-ben használt value Ctt kulcsszó, a jellemzőnek átadott 
balértéket jelöli (pl. 9). Bármelyik kulcsszó elhagyásával írha- 
tunk csak olvasható vagy csak írható jellemzőt is. 

A jellemző beállításakor általában értékhatár-ellenőrzést is vég- 
zünk. A példában csak pozitív számokat fogadunk el, más szá- 
moknál egy kizárást (exception) hajtunk végre, amelyet a hívó 
metódusnak le kell kezelni. Erre még visszatérünk egy későbbi 
részben. Amit nagyon fontos látnunk, hogy a jellemzők kényel- 
mes lehetőséget biztosítanak a mezők ellenőrzött hozzáférésé- 
re, de a metódusok nehézkesebb hívási formátumát nélkülözve. 
Emellett a jellemzők mögött sokszor nem valódi tagváltozók áll- 
nak, hanem például valamilyen számított érték. Pont az a sze- 
repük, mint a metódusoknak: elfedni a fizikai megvalósítást, az 
osztály belső szerkezetét. 


Konstruktorok, destruktorok 

Minden osztálynak van legalább egy speciális metódusa, amit 
konstruktornak hívunk. Ha mi magunk nem hozunk létre, akkor 
is keletkezik egy, amit a fordító hoz létre nekünk. A konstruk- 
torok neve megegyezik az őket tartalmazó osztály nevével, 
nincs visszatérési értékük, de lehetnek paramétereik. Nézzünk 
bele a Kutyus osztályba: 


Class Kutyus ( 
Kútyus(d tsz 
Kutyus(string szin) ( ...) 
) 


Neki mindjárt két konstruktora is van, az egyik nem vár paramé- 
tert, a másik igen, a kutya színét string típusban. 

A konstruktor egyszer hívódik meg, akkor, amikor létrejön az osz- 
tályból egy példány. Feladata az objektum belső kiinduló állapo- 
tának, például tagváltozók értékének beállítása induló értékre. 
Több változat esetén melyik konstruktor hívódik meg? Az a lét- 
rehozás módjától függ. A 


Kutyus k - new Kutyus( ); 


CU: UR: 





eTu8peAY LAN" 


(zsöú "ÍT) 


yosndTr3deTe [357 


ek 


.NET alaptípusok 


rész) 


(di 


.NET Akadémia 


e? 


az első konstruktort hívja meg, mert nem adtunk át 
paramétert az osztálynév után a new-ban. A máso- 
dik verziót akkor tudjuk meghívni, ha átadunk egy 
string típusú paramétert az objektum létrehozásakor: 


p 


Kutyus k - new Kutyus( "cirmos" ); 


Ha vannak konstruktorok, amelyek az objektumok születésekor 
futnak le, akkor joggal várhatjuk, hogy lesznek destruktorok is, 
amelyek akkor hívódnak meg, mielőtt az objektum elpusztul. Mi- 
kor pusztul el egy objektum? Azokban a nyelvekben és progra- 
mozási környezetekben, ahol nekünk kell kézzel létrehozni és 
felszabadítani az objektumokat, van a new operátornak párja, 
általában a delete operátor, amivel kijelölhetjük mikor szeret- 
nénk felszabadítani egy példány által elfoglalt memóriát. Ebben 
az esetben egy destruktor végrehajtódásának ideje teljesen 
meghatározott - meghívom a delete Kiskutya-t, erre megsemmi- 
sül a kiskutya objektum, de előtte meghívódik a destruktor. 
Ilyen például a klasszikus C----os környezet. De nem ilyen a 
.NET! A .NET tervezőinek nehéz döntési kérdésben kellett elha- 
tározni magukat: milyen legyen a memóriakezelés: a programo- 
zó által vezérelt, azaz a programozónak kell felszabadítania a le- 
foglalt objektumokat, vagy a futtatórendszer tegye ezt meg? 
Igazából az első gyorsan kiesett, mert - tanulva a rengeteg me- 
móriaszivárogtató alkalmazásból - az MS úgy döntött, nem ér- 
demes a fejlesztőkre bízni a memória kezelését. 

A második módszer (amikor a keretrendszer szabadítja fel a me- 
móriát, ha már nem hivatkoznak egy objektumra) még mindig 
kétféleképpen valósítható meg: vagy számoljuk, hogy hány hi- 
vatkozás mutat egy objektumra, és ha már egy sem, azonnal fel- 
szabadítjuk, ez például a COM és a VB6 megközelítése. 

Ennek egy alternatívája, ha csak időnként, alkalmanként fut le egy 
szemétgyűjtő algoritmus, ami megnézi mely memóriabeli objektu- 
mokra nem mutat már semmilyen referencia, s azokat felszabadít- 
ja. Ebben a kérdésben volt csak igazán nagy meccs az MS-en be- 
lül! A két módszer nagyon hasonló, alapvető különbség abban van, 
hogy mikor semmisül meg egy már nem használt objektum: az el- 
ső esetben azonnal, ha már nem hivatkozik rá senki (ld. VB obj - 
Nothing), azaz a megsemmisülés ideje meghatározható azzal, 
hogy mikor dobjuk el explicit az objektumra mutató referenciát. 
A .NET a második stratégiát követi. A nem használt objektumo- 
kat felszabadító szemétgyűjtő nem liheg a programunk nyaká- 
ban, és lesi árgus szemekkel mikor van egy kis takarítanivaló, 
hanem időnként, leginkább külső kényszer (fogy a szabad me- 
mória) hatására kezd el működni. Ilyenkor kidobja a már senki 
által nem hivatkozott, így senki által fel nem használható ob- 
jektumokat, majd visszavonul. 

Mitől más a szemétgyűjtés a programozók szemszögéből mint a 
hivatkozásszámlálás? Nos, a nagy különbség az, hogy a meg- 
semmisülés időpontja nem meghatározható, nem determinisz- 
tikus! Azaz nem építhetünk a szó klasszikus értelmében vett 
destruktorok működésére, mert lehet, hogy csak egy óra múlva 
semmisül meg egy nem használt objektum! A .NET programozás 
egyik fontos eleme ennek a ténynek a realizálása! Ha például 
egy objektumban megnyitunk egy állományt, és úgy írjuk meg 
az osztályunkat, hogy a destruktor fogja lezárni a fájlt, akkor le- 
het, hogy órákig nyitva marad (nem töri magát a kukás), ami 
gondokat okozhat. Feleslegesen foglalunk rendszererőforráso- 
kat, vagy éppen egymás működését akadályozhatják a különbö- 
ző folyamatok. Ez a tény nagyon fontos, úgyhogy ki is emelem: 


A .NET Runtime felszabadítja az általunk már nem használt ob- 
jektumok memóriaterületeit, de nem tudja automatikusan leke- 
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zelni az egyéb nem menedzselt erőforrásokat (ablakkezelők, 
fájlkezelők, adatbáziskapcsolatok, satöbbi). Az a mi feladatunk. 


Mit lehet tenni? Ne építsünk a destruktor megszokott, determi- 
nisztikus működésére, így minden erőforrást zárjunk le azonnal, 
amint nincs rá szükségünk. Ne rakjunk erőforrás-felszabadító 
kódot a destruktorba! 

A CH a Cs4-os destruktor formátumot használja: 


Class Kutyus ( 
-Kutyus() ( ...) 


Azaz pont olyan, mint egy paraméter nélküli konstruktor, csak 
egy kiskigyó (-) van a neve előtt. 

Az alábbi kódrészletben tanulmányozhatjuk egy Kutyus objek- 
tum élettartamát. 


using System; 
class KonstruktorokEsDestruktorok ( 
public static void Main() ( 

Kutyus k - new Kutyus( ); 
Console.ReadLine( ) ; 
k - null; 
Console.WriteLine( "Kutyus kidobva."); 
Console.ReadLine( ) ; 


class Kutyus ( 
//Konstruktor 
public Kutyus() ( 
Console.WriteLine( "Kutyus 
4 konstruktor lefutott"); 
) 
//Destruktor 
-Kutyus() ( 
Console.WriteLine( "Kutyus 
b destruktor lefutott"); 
) 
) 


A kimenet első része: ,Kutyus konstruktor lefutott". Ekkor Entert 
kell ütni a program folytatásához. Ezután az objektumra mutató re- 
ferenciát rögtön kinullázzuk, s referenciaszámlálót alkalmazó rend- 
szerben azonnal lefutna a destruktor. De nem a .NET-ben! A nullá- 
zás hatására nem történik semmit. A destruktor csak akkor hívódik 
meg, ha a második Enter hatására a program futása befejeződik. 
Vannak nyelvek, amelyek nem támogatják a destruktor közvet- 
len definiálását. Ez nem probléma, mert valójában a Ct destruk- 
tor is csalás, az alábbi kódra fordul le: 


protected override void Finalize() ( 
try 
( 
// Ide kerül a destruktor kódja 
) 
finally 


( 
base.Finalize(); 


UO. UE: 


Azaz a destruktor helyett készül egy Finalize() virtuális metódus, 
ami felüldefiniálja az ősosztályból örökölt metódust. Ennek tör- 
zsében lefut a destruktorban kijelölt kódunk, majd meghívódik az 
alaposztály Finalize() metódusa is, hogy neki is legyen alkalma 
felszabadítani az általa (esetlegesen) lefoglalt erőforrásokat. 

Az olyan nyelvekben, amelyekben nincs destruktor, hasonló mó- 
don a Finalize() felüldefiniálásával hozhatunk létre takarítókó- 
dot, ügyelve az alaposztály Finalize() meghívására is. Ctt-ban 
viszont ez nem megengedett, ott a kiskigyó destruktor szintak- 
szist kell használnunk. 

A destruktorokat csak akkor használjuk, ha tényleg szükség van 
rájuk. A szemétgyűjtőnek külön kell még egyet fordulni a 
destruktorok meghívásához, azaz ezzel pluszmunkát adunk a 
szemétgyűjtőnek (és persze a processzornak) . 

Determinisztikus erőforrásfelszabadításhoz általában az IDis- 
posable interfész Dispose metódusát valósítjuk meg, majd exp- 
licit meghívjuk akkor, ha fel akarjuk szabadítani az erőforráso- 
kat. Ezzel, valamint a szemétgyűjtő működésével és idomításá- 
val egy későbbi számban még foglalkozunk. 


Érték és referencia szerinti típusok (Value types és Reference 
types) 

Az eddig létrehozott osztályaink referenciatípusúak voltak, ami azt 
jelenti, hogy a new operátorral hoztuk létre őket a szemétgyűjtő 
által kezelt memóriában. Így például a korábbi példánkban k vál- 
tozó a Kutya osztály egy memóriabeli példányára mutató pointer 
(referencia, menedzselt világban nem illik pointerekről beszélni), 
nem pedig a tényleges kutya objektum. Amikor az értékadásokban 
referenciatípusokat használunk, akkor mindig csak a referencia ér- 
téke másolódik át, a valódi objektumhoz nem nyúlunk hozzá. 
Ezzel szemben az primitív alaptípusok, például az Int32 más- 
ként működnek. ők a vermen jönnek létre, így automatikusan 
felszabadulnak, ha az őket deklaráló metódus lefutott. Nincs 
szükségük a kukásra. Ami ennél is fontosabb, hogy amikor ér- 
tékadásban használjuk őket, akkor a tényleges értékük másoló- 
dik át, nem csak egy rájuk mutató pointer. 

Saját magunk is létrehozhatunk érték szerinti típusokat, egysze- 
rűen a class kulcsszó helyett a struct kulcsszóval kell létre- 
hozni őket. Automatikusan öröklődnek a System. ValueType 
osztályból, hasonlóan, ahogy a referencia típusú objektumok a 
System. Object-ből. 

Miért kellett bevezetni ezt a megkülönböztetést? Gondoljunk 
csak egy byte-ot ábrázoló típusra! Mennyi a tényleges tárigénye 
egy ilyen típusnak? 1 byte. És mennyi kell hozzá, ha a memó- 
riában hozzuk létre referencia típusként? Ha egy referencia 4 
byte, akkor minimum 4-1 - 5 byte. Ez nem túl biztató. De az 
igazi probléma nem is annyira a hely, hanem a memórialefogla- 
lás sebessége. Melyik a gyorsabb objektumfoglalási módszer? 
Letolni a veremmutatót x bájttal, vagy keresni helyet a mene- 
dzselt memóriában, adminisztrálni a helyfoglalást, és visszaad- 
ni egy mutatót? Nyilvánvalóan az első megoldás lényegesen 
gyorsabb, ráadásul a megsemmisítés automatikus lesz. 

Az érték szerinti típusok hátrányai akkor kezdenek megmutat- 
kozni, amikor nagyméretű típust akarunk létrehozni. Egy bizo- 
nyos határ fölött a nagyméretű, értéktípusú objektumok máso- 
lása több időt igényelhet, mint referenciatípusként a lefoglalá- 
sa jelentett volna. Emiatt az érték szerinti típusok leginkább 
kisméretű objektumok tárolására alkalmasak (durván 16 byte a 
határ). Viszont kis adatmennyiségek használatára sokkal gyor- 
sabban tudnak lenni, mint a referencia típusok. Például tekint- 
sünk meg egy komplex számokat tároló típust. 
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public struct Complex ( 
double real, imaginary; 


) 
Vagy egy pixel koordinátáit leíró típus: 


public struct Point ( 
I06-xgT 


Az összes adatelrejtési elv, amit az osztályoknál elmondtam, ér- 
vényes az érték szerinti típusokra is, azaz használjunk jellemző- 
ket és metódusokat a belső részletek elfedésére. 

Hasonlóan az osztályokhoz, nekik is lehetnek konstruktoraik, de 
csak paraméterezettek: 


public Point(int x, int y) ( 
this.x -— x; this.y — y; 
) 


Éppúgy létre kell belőlük hozni egy példányt, mint az osztályok- 
ból, a new operátorral: 


Point p - new Point(); 


Ha létrehozáskor azonnal inicializálni akarjuk a struktúrát, akkor 
például használhatjuk az előbbi paraméterezett konstruktort: 


Point p - new Point(L,4); 


A legtöbb alaptípus használatakor elég kényelmetlen lenne a 
new használata, ezért élhetünk egy rövidített formátummal is: 


//Létrehozás 
//Használat 


Point r; 
vé: xes 30 bye s 


Vagy például egy 32 bites egész szám létrehozása egyenértékű 
megoldások: 


int i - new int(); 
int j - new System.Int32(); 
116t"ki 


A new nélküli esetekben a tagváltozók automatikusan kinullázódnak. 
Ami első ránézésre nagyon szokatlan, hogy az érték szerinti típusok 
is implementálhatnak interfészeket. Például a legtöbb alaptípus imp- 
lementálja az IComparable interfészt, amire többek között a ke- 
retrendszer által nyújtott tömbrendezések automatikusan építenek, 
hogy össze tudjanak hasonlítani két példányt az adott típusból. 


Ilyen a BOX! 
Többször használtuk már a Console osztály WriteLine metódusát 
egész számok kiíratására is, például: 


int j - 10; 
Console.WriteLine( 0)", j); 


Pedig a WriteLine ezen változata egy System. Object típu- 
sú referenciát vár második paraméterül, nem egy integert. Ak- 
kor miért nem jelez hibát a fordító? Csak nem lehet az, hogy egy 
érték szerinti típust, mint az int el lehet érni egy Ob ject típu- 
sú referencián keresztül? 


eü: Ug. 
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De bizony! De hogyan lehet egy veremben lefoglalt 

érték szerinti típust pointeren keresztül elérni? Csak 

nem a verebe mutat ilyenkor a referencia? Természe- 

tesen nem. Amikor egy érték szerinti típust kell refe- 

rencián keresztül elérni, akkor a fordító olyan kódot gene- 

rál, amiben a típusnak megfelelő memóriát lefoglalja a szemét- 

gyűjtő által menedzselt memóriában, és átmásolja a típus tar- 

talmát a veremből. Ezt hívjuk Boxing-nak, hisz bedobozolja a 
változó tartalmát egy másik memóriahelyre. 
Emiatt olyan furcsa kódokat lehet írni, mint: 


int j-z JO; 
object o - j; //box 


Miért jó ez? Ha minden - és tényleg minden - típust elérthetünk 
object típusú referencián keresztül, akkor ez azt jelenti, hogy pél- 
dául egy kollekcióban bármilyen típust tárolhatunk, hisz elég csak 
az object referenciákra megírni a szükséges elérőmetódusokat, a 
nem object típusok automatikusan boxolódnak ob ject-té. 

Mi a helyzet a visszaúttal, hogyan lehet kicsomagolni egy bedo- 
bozolt érték szerinti típust? Visszafelé már nem teljesen sima az 
ügy, mert egy általános ob ject referencia által hivatkozott me- 
móriaterületről kell visszamásolni az értéket a veremre. Ha pél- 
dául beboxolunk egy 16 bites egészet a memóriába, majd azt 
vissza akarnánk nyerni mint egy 32 bites számot, akkor abból 
nagy baj lehetne, ha túlolvasna az értéket másoló eljárás az el- 
ső két bájton. Ezért az egyértelmű szándék kijelölésére vis- 
szirányban egy kasztoló operátorral jeleznünk kell, hogy mivé 
kell visszaalakítani a referenciát: 


//Hibás: Cannot implicitly convert 
//type "object" to "int" 

int k 5 o; 

//Rendben van. 

int m - (int)o; 


A kényelmes átjárás miatt könnyedén lehet írni általános töm- 
böket vagy metódusparamétereket, de nyilvánvalóan ára van az 
általánosításnak: a boxolás lassítja a programok futását. Például 
egy specializált kollekció, ami csak egy adott érték szerinti tí- 
pust tud tárolni, de azt közvetlenül, típusos elérő metódusokon 
keresztül (boxolás nélkül), jelentősen gyorsabb lehet az általá- 
nos object referenciát használó társánál. A .NET keretrendszer 
tartalmaz néhány általános kollekciót, és pár specializáltat is. 
Sajnos azonban igazi, boxolás nélküli, primitív típusokat kezelő 
típusos kollekciója nincs. Az [1] címről letölthető egy erősen tí- 
pusos kollekció megvalósítás (coll.cs), amiben integereket tá- 
rolhatunk a keretrendszer ArrayList nevű kollekció osztályhoz 
hasonlóan, azaz egy változtatható hosszúságú tömbként. Az 
osztály egy sor átírásával könnyedén átalakítható más típusú ér- 
ték szerinti típus tárolására, de sajnos ez azt jelenti, hogy min- 
den típushoz le kell másolni és át kell írni a teljes forráskódot. 
Hej, ha lennének template-ek, mint a C---ban... 
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A boxing teljesítménycsökkentő hatásának demonstrálására írtam 
egy tesztelő alkalmazást (box.cs). Ebben paraméterezhető módon 
ki lehet próbálni az általános ArrayList és a saját típusos kol- 
lekció használatát nagyszámú 32 bites egész tárolására és visszaol- 
vasására. A tesztelő programban megfigyelhető a nagyfelbontású 
(c1 microsec) rendszeróra használata, amihez a dueryPerfor- 
manceCounter és a dueryPerformanceFreguency API függ- 
vények köré írtam egy egyszerűen használható csomagoló osztályt. 


Egy mérés nem mérés, ezért paraméterezhető számban megis- 
mételhetjük a tömböket terhelő hívásokat. Az így keletkező át- 
lagok elég jól reprodukálható eredményeket adnak. Nyilván egy 
multitaszkos operációs rendszeren lehetetlen kizárni a többi 
program ráhatását, de azért néhány bemelegítő futtatás után 
kielégítően stabil eredményeket kapunk. Nagyon fontos, hogy 
legyen elég szabad RAM a gépben, hogy ne okozzunk lapozást a 
tömbök helyfoglalásakor. 

Az alábbi táblázatban összefoglaltam néhány mérés eredményét: 














Elemek "Mérések Végrehajtási Végrehajtási idő  Idő- 
száma száma idő Array- specializált nyereség 
List-tel [ms]  kollekcióval [ms] szorzó 
100.000 10 196,64 63,23 340 
100.000 10 206,27 57,08 3,61 
100.000 10 196,70 57,45 3,42 
300.000 10 1142,08 215,17 5,30 


Az első három sorból látszik, hogy a mérés jól reprodukálható, 
nincs 1099-nál nagyobb szórás a mért értékekben. Láthatóan a 
boxolást kiküszöbölő specializált kollekció többszörösen gyor- 
sabb az általános típusnál. A forrásokat letöltve [1] otthon bár- 
ki megismételheti a méréseket a saját gépén, illetve ötleteket 
kaphat egy specializált kollekció megírására. Ha egy alkalmazás- 
ban nagyon fontos nagy elemszámú alaptípus hatékony tárolá- 
sa, akkor érdemes elgondolkodni egy saját verzión. 

Mindezek ellenére nem szeretném, ha azt éreznék, hogy a box- 
ing egy ártalmas és teljesen felesleges technológia. A két típus 
megkülönböztetése nagyon jelentős teljesítménynyereséget 
eredményez, ha rövid típusok tárolására és paraméterek átadá- 
sára érték szerinti típusokat használunk. Egy másik, J-vel kez- 
dődő technológiában nincs ez a megkülönböztetés, csak refe- 
renciatípusok vannak, ami miatt egyes teljesítménycentrikus 
helyeken kénytelenek nagyobb számú primitív típust átadni pa- 
raméterül egy egyszerű struktúra helyett, a referencia típusok 
okozta teljesítményproblémák miatt... 


Soczó Zsolt MCSE, MCSD, MCDBA 
Zsolt.Soczo(onetacademia. NET 


A cikkben szereplő URL-ek: 


[1]: Letölthető példakódok. 
http://technet.netacademia.net/download/net 
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Átjárás a relációs és az xml világ között 


Az xml nagyszerű eszköz adatok átvitelére, heterogén rendszerek közötti 
információcserére, de csapnivaló adattárolásra. Redundáns és csak lassan lehet belőle 
kihámozni a tényleges információtartalmat. Hatékony adattárolásra már régóta 
léteznek megfelelő eszközök, az adatbázisok. A legtöbb adatbázis azonban relációs 
elvekre épült, téglalap alakú információhalmazokban gondolkodik, amelyek között 
kapcsolatok vannak definiálva. Hogyan valósítható meg az átjárás két világ között, 

a lehető leghatékonyabb módon? Erre keresem a választ a .NET eszközeivel. 


A kihívás 

Hogyan lehet relációs adatbázisban tárolt táblák adatait xml-lé 
transzformálni, és visszafelé, hogyan lehet xml-ben kapott infor- 
mációkat relációs adatbázis táblákban eltárolni? Leggyakrabban 
különböző rendszerek közötti kommunikációban kell megvalósíta- 
ni a konverziót, amelyben például két cég interneten keresztül, 
xml formátumban kommunikál egymással, de minkét oldalon relá- 
ciós adatbázisban tárolják a küldendő vagy fogadandó adatokat. 
Másik lehetséges felhasználás az xml könnyű transzformálható- 
ságát szeretné kihasználni (XSLT-vel), azonban ehhez elérhető- 
vé kellene tenni a relációs adatokat xml formátumban. Nézzük 
meg, milyen lehetőségeink vannak! 

Olyan adatbáziskezelő esetén, amely közvetlenül képes xml ki- 
menetet generálni és xml formátumú adatokat feldolgozni, nincs 
különösebb gond az átjárással. Ilyen például az SOL Server 2000, 
erről már írtam az újság hasábjain tavaly ősszel. Ebben az eset- 
ben a konverziós eljárásokat megírták helyettünk, nekünk csak 
definiálni kell az adatbázistáblák és az xml dokumentum közöt- 
ti leképezést. Erre a legkézenfekvőbb eszköz az XML séma, amely 
szinte minden szükséges konstrukciót tartalmaz az átjáráshoz. 
XML sémával definiálni tudjuk az xml oldal szerkezetét, az adat- 
bázis szerkezete adott, azt az adatbázistáblák létrehozásakor 
konstruáltuk meg. Ami nem része az xml sémának, az maga a le- 
képezés a táblák és az xml tagok között. Ezzel az információval 
viszont könnyedén kiegészíthető a séma, hiszen külön névtérben 
bármilyen kiegészítő xml tartalommal megtűzdelhetünk (anno- 
tálhatunk) egy sémát, attól az eredeti működése nem változik 
meg. Viszont egy olyan alkalmazás - például az SOL Server OLE- 
DB meghajtó - ami értelmezi a kiegészítéseket, képes forrás xml 
adatokat SOL parancsokká leképezni, valamint tud olyan SOL pa- 
rancsot legyártani, amely a sémának megfelelő xml kimenetet 
generál. Többek között erről szól az SOL Server xml támogatása. 
Ha nem ilyen rózsás a helyzet, azaz a támogatandó adatbázisok 
nem rendelkeznek beépített xml támogatással, akkor szükség 
lesz egy olyan keretrendszerre, amely képes a híd szerepének 
betöltésére. Jöjjön az ADO.NET! 


ADO.NET alapvetés 

Mit keres egy adatbáziselérő technológia az XML rovatban? A 
.NET-ben megszűnt az éles határvonal az hierarchikus XML, és a 
sík relációs világ között, az ADO.NET adatbáziskezelő osztályai 
és az előző két részben látott XML osztályok jó barátságban él- 
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nek, és remekül együttműködnek egymással. A kapcsolat megér- 
téséhez induljunk el a relációs világ irányából. 

Az ADO.NET részletes bemutatatása nem célunk, ezzel majd a 
.NET Akadémia sorozatban egy külön számot fogunk eltölteni. 
Most csak a legszükségesebb ismereteket mutatjuk be. Az adat- 
elérő osztályok a System.Data névtérben vannak. SOL Server 
elérésére a specializált Sgl... kezdetű osztályokat használjuk, ál- 
talános OLE-DB meghajtóval rendelkező adatokhoz az Olebb... 
kezdetű osztályok valók. A példákban az egyszerűség kedvéért 
az Sgl osztályokat használom, de nem használom ki az SOL 
Server beépített xml lehetőségeit. 

Adatbáziskapcsolat kiépítésére az SglConnection osztály haszná- 
latos, nagyon hasonlóan az ADO-beli Connection objektumhoz. 


//Adatbáziskapcsolat kijelölése (itt még nem 
//kapcsolódik az adatbázishoz) 

SglConnection c - new SglConnection("Initial 
B CatalogzsNorthwind;Data Source-(10cal); 

4 Integrated SecurityzSSPI;"); 


A lekérdezéseinket SglIDataAdapter objektumon keresztül hajt- 
juk végre: 


//DataAdapter felépítése 
SgliDataAdapter a - new SglDataAdapter( 
4 "SELECT £ FROM Products", c); 


A lekérdezés eredményhalmazát DataSet objektumban tároljuk. 
A DataSet az univerzális adattároló eszközünk, amely leginkább 
memóriabeli adatbázisként fogható fel. 


DataSet ds - new DataSet(); 


Az eddig még üres DataSet-ünket a DataAdapter segítségével 
töltjük fel: 


7/A parancs végrehajtása. Az eredményhalmaz 

7//a Termek táblában jelenik meg. 

a.Fill(ds, "Termek"); 

A DataAdapter megnyitja az adatbáziskapcsolatot, végrehajtja a 


konstruktorban kijelölt lekérdezést, és lezárja a kapcsolatot. A 
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DataSet-ünkben létrejön egy Termek nevű tábla 
. — (DataTable objektum), amely a lekérdezés eredmé- 
nyét tárolja. Az így nyert tábla illetve DataSet teljen 
független a forrásadatbázistól, attól el van választva. 
Egy DataSet tetszőleges számú táblát tárolhat, a táblák kö- 
zött relációkat definiálhatunk pont úgy, mint egy valódi adatbá- 
zisban. Emellett kulcsokat, megszorításokat is létrehozhatunk a 
oszlopokon, azaz valóban úgy viselkedik, mint egy igazi adatbázis. 
A lekérdezés kimenetét tároló tábla szerkezetét a lekérdezés 
oszlopai szabják meg. Ezt könnyedén megtudhatjuk a 
WriteXxmISchema metódus meghívásával: 


StreamWriter w - new StreamwWriter("sl.xml"); 
ds.WriteXmlSchema( w) ; 


Tekintsünk bele a kimenetbe (51.xml): 


£x?xml version-"1.0" encoding-"utf-8"?2 
€xs:schema id-"NewDataSet" 
Wxmlns:xszhttp: //www . w3 . org/2001/XMLSchema 
Wxmlns:msdataz"urn:schemas-microsoft-com: 
$xml-msdata"2 
€xs:element name-"NewDataSet"2 
£xs : complexType2 
€xs:choice maxOccurs-"unbounded"2 
€xs:element name-"Termek"? 
£xs : complexType2 
£xs: seguence? 
€xs:element name-"ProductID" 


4 typez"xs:int" minOccursz"DO" /52 
£xs:element name-"ProductName" 
4 type-"xs:String" minOccursz"O" /5 


£xs:element name-"Discontinued" 
4 types-"xs:boolean" minOccursz"O" /2 


£/xs:seguence2 
£/xs:complexType2 
£/xs:element2 
£/xs:choice2 
£/xs:complexType? 
£/xs:element2 
£/xs:schema2 


Ez egy közönséges XML séma (XSD) fájl. Olyan xml dokumentu- 
mokat ír le, aminek a gyökéreleme a NewDataSet nevű elem, eb- 
ben tetszőleges számú Termek elem helyezkedik el. Ezek az 
adatbázisból lekérdezett sorokat tárolják, láthatóan az oszlopok 
azonos nevű gyermekelemekre képződtek le. 

Örülünk ennek a szép sémának, de nekünk a tényleges adatokat 
tartalmazó xml kimenet a fontos. Mi sem egyszerűbb: 


ds.WriteXml( "termekekl.xml" ) ; 
Kukkantsunk bele a generált dokumentumba: 


£X?xml versions"1.0" standalone-"yes"?2 
CKNewDataSet? 
cKTermek2 
KProductID21C/ProductID2 
LxProductName2Chaik/ProductName?2 


cKDiscontinued?falsek/Discontinued? 
£/Termek2 
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cKTermek2 
LxProductID22£/ProductID2 
c/Termek2 
cx/NewDataSet2 
A WriteXml() természetesen nemcsak fájlba képes írni, hanem 
tetszőleges kimeneti adatfolyamba is. Például egy xml kimene- 


tet generáló webform (aspx, . NET-es ASP) esetén közvetlenül ír- 
hatunk a kimeneti adatfolyamba: 


Response.ContentType - "text/xml"; 
ds.WriteXml(Response.OutputStream) ; 
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0 DataSet xml kimenete böngészőben 


Az xml kimenet testreszabása 

Láttuk, hogy a DataSet feltöltése után kiolvashatjuk a betöltött 
- pontosabban a generálandó xml - adatok szerkezetét a 
WriteXmISchema()-n keresztül. Nem lehetne ezt visszafelé is 
megtenni? Egy sémával definiálni az xml kimenet szerkezetét, 
rátölteni a relációs adatokat, majd kinyerni az általunk igényelt 
xml kimenetet? Természetesen lehet! 

Tegyük fel, hogy a ProductID-t, a CategoryID-t és a SupplierID- 
t szeretnénk kiemelni a megfelelő Termek elemek attribútuma- 
ként. Ehhez így alakítjuk át a sémát: 


€xs:element name-"Termek"? 
£xs:complexType2 
£xs :seguence2 
€xs:element name-"ProductName" ... /2 


£/xs:seguence2 
£Kxs:attribute name-"ProductID" 
$  types"xs:int" uses"reguired"/2 
€xs:attribute name-"CategoryID" 
4 type-"xs:int" uses"optional"/2 
£Kxs:attribute name-"SupplierID" 
4 types-"xs:int" uses"optional"/2 
£/xs:complexType2 
£/xs:element2 


Mielőtt feltöltenénk a DataSet-et a DataAdapter-rel, adjuk meg 
neki az általunk kialakított sémát: 


zÜBZ:. S: 


ds.ReadXmlSchema( "s2.xml"); 
a.Fill(ds, "Termek" ); 
ds.WriteXml( " termekek2 . xml" ) ; 


Íme a hőn áhított xml kimenet, az ID-kkel az attribútumokban 
(termekek2.xml) : 


cKNewDataSet2 
cKTermek ProductID-"1" CategoryID-"1" 
$ SupplierID-"1"2 
KXProductName2Chaik/ProductName2 


Típusos DataSet-ek 

Ha a DataSet képes xml séma alapján saját formátumú xml ki- 
menetet generálni, akkor miért nem lehet szorosabban összehá- 
zasítani a DataSet struktúráját meghatározó XSD sémát a Data- 
Set-el? Azaz készíthetnénk egy specializált DataSet osztályt, 
ami már eleve tartalmazza az oszlopok saját, típusos definíció- 
ját. Ez nem csak az xml kimenet egyszerűbb generálásában se- 
gítene, de az oszlopokra erősen típusos módon tudnánk hivat- 
kozni, így a relációs adatok közvetlen elérésekor is már a kívánt 
típusban érhetjük el az oszlopokat, így már a fordító ellenőriz- 
ni tudja az adatelérés helyes típusát. 

Nézzünk erre egy példát! Az előbb létrehozott általános DataSet 
esetén a Termek táblát a DataSet Tables kollekcióján keresztül 
érhetjük el, majd végigmehetünk az összes sor minden oszlopán: 


DataTable t ds.Tables["Termek" ]; 
int numCols - t.Columns.Count; 
for(int row - 0; row £ t.Rows.Count; rowtt) ( 
Console.WriteLine("Sor: (0) ", row); 
DataRow r - t.Rows(row]; 
for(int col - 0; col £ numCols; coltt) ( 
Console.WriteLine( (0), (1): (2 ", 
t.Columns[col].ColumnName , 
t.Columns[col)].DataType, r[col]); 


Kimenet: 


Sor: 21 

ProductID, System.Int32: 2 
CategoryID, System.Int32: 1 
SupplierID, System.Int32: 21 
ProductName, System.String: Chang 


Discontinued, System.Boolean: False 

Látható, hogy az oszlopoknak van adattípusa, ami a megfelelő 
háttérsémából képződik futásidőben. A probléma oka pont ez. 
Ha például a Discontinued oszlop tartalmát típusosan meg akar- 
juk ragadni, akkor azt kasztolnunk kell bool típussá: 

bool disc - (bool)r["Discontinued"]; 

Ha "neadjisten rosszul tudjuk az adattípust, vagy például meg- 
változott az adatbázis sémája, akkor erre csak futás közben, a 


konverzió tényleges végrehajtásakor derül fény: 


int disc - (int)r["Discontinued"]; 
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Unhandled Exception: 
System.InvalidCastException: 
Specified cast is not valid. 


Ha a DataSet oszlopainak típusa nem futásidőben, hanem 

már fordításkor ismertek lennének, akkor már a fordító észre- 
venné a helytelen konverziót. Irány a típusos DataSet! 

A típusos DataSet egy általános DataSet osztályból származik 
örökléssel, így annak összes tulajdonságát magán viseli, ám az 
oszlopai adattípusát előre definiáljuk, és minden oszlophoz ké- 
szítünk egy típusos adatelérő jellemzőt. Egy ilyen specializált 
DataSet osztály megírása igencsak mechanikus babramunka len- 
ne, ezért jelentős segítséget kapunk hozzá. 

A DataSet szerkezetét egyszerűen leírjuk egy XSD sémával, majd 
az xsd.exe segítségével legeneráltathatunk egy specializált, tí- 
pusos DataSet osztály forráskódot, amelynek pontosan olyan 
lesz a szerkezete, mint amilyet a séma definiál. Azaz ebben az 
esetben nem futásidőben töltjük be a sémát, hanem még szer- 
kesztési időben , dolgozzuk bele" a DataSet-be. 

Kiindulásként szükség van egy xml sémára. Ezt megírhatjuk kéz- 
zel is, lévén, hogy egy közönséges xml fájlról van szó. Azonban 
elérkezett a pont, hogy bevessük a Visual Studio.NET-et is! 

Egy tetszőleges projektet létrehozva (én Console alkalmazást hasz- 
náltam) a Project/Add New Item menüpont mögötti párbeszédab- 
lakban keressük ki az XML Schema típust, és adjunk neki valami ne- 
vet. Ekkor létrejön egy üres xml séma fájl (.xsd) , amit tervezési né- 
zetben láthatunk. A kívánt struktúrát kialakíthatjuk a Toolbox-on 
található alapösszetevőkből: elemek, attribútumok, csoportok, 
komplextípusok, satöbbi. Ez a módszer akkor jöhet jól, ha nem ér- 
hető el a forrásadatbázis, amely kimenetéhez írunk DataSet-et. 
Mostani példánk egy összetettebb DataSet lesz, melynek sémá- 
ja kétféle táblát fog tartalmazni: Categories és Products. Ők a 
Northwind adatbázis termékeket és termékkategóriákat tároló 
táblái. A két tábla között ráadásul szülő-gyermek kapcsolat is 
van, egy termékkategóriához több termék is tartozhat. A sémá- 
ban ezt is definiálhatjuk, így majd a DataSet tábláinak feltölté- 
sekor már működni fog az idegenkulcs megszorítás, így eleve 
nem generáltathatunk bele inkonzisztens adatokat. 

A két tábla szerkezetét kézzel is összerakhatjuk, ha ismerjük az 
adatbázistáblák struktúráját. Ennél azonban jóval egyszerűbb, 
ha a Server Explorer ablakban felveszünk egy adatbáziskapcso- 
latot, és ráhúzzuk a táblákat a tervezőre. 
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5 Már benn vannak a forrástáblák, csak még nem a megfele- 
lő kapcsolatban ki 


Alakul a dolog, csak éppen nincs szükségünk a két Document elem- 
re, hanem azt szeretnénk, ha a Categories és a Products egy gyö- 
kérelem közvetlen gyermekelemei lennének. Bizonyára ez elérhető 
a tervezővel is, azonban hamarabb célhoz érünk, ha az xml forrás- 
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nézetben egyszerűen kézzel átmozgatjuk a Products 
elemet (minden belső tartalmával együtt) a Categories 
elem mögé. Rövidítve így fog kinézni a séma: 


€xs:element name-"Document"2 
£xs : complexType2 
$£xs:choice maxOccursz"unbounded"2 
£Xxs:element name-"Categories"2 
£xs : complexType2 
£xs : seguence2 
£xs:element name-"CategoryID" 
msdata : ReadOnly- "true" 
msdata : Autolncrement-"true" 
types"xs:int" /5 
£€xs:element name-"CategoryName" 
type-"xs:Sstring" /2 
£/xs:seguence2 
£/xs:complexType2 
£/xs:element2 
£xs:element name-"Products"2 
£xs : complexType2 
£xs : seguence2 
€xs:element name-"ProductID" 
type-"xs:int" /2 
£xs:element name-"ProductName" 
type-"xs:Sstring" /2 
£/xs:seguence? 
£/xs:complexType2 
£/xs:element2 
£/xs:choice2 
£/xs:complexType2 


A Document elemet átnevezhetjük Termék katalógusra. Sajnos a 
tervező önmagában inkább csak egy kiinduló váz elkészítésére 
alkalmas, a hatékony munkához mindenképpen elengedhetetlen 
az XSD ismerete, mert időnként bele kell nyúlni az xml forrásba. 
Már csak a két tábla közötti kapcsolat definiálása van hátra, eb- 
ben jó a tervező. Mintha csak egy adatbázistervező programot 
használnánk, a Products elem CategoryID nevű elemét húzzuk rá 
a Categories elem CategoryID elemére. Az előugró dialógusab- 
lakban ügyeljünk arra, hogy jól jelöljük ki melyik a szülőtábla 
(Categories) és melyik a gyermek (Products). 

Ezzel készen is van a sémánk! 





5 Készen van a két táblát tartalmazó xml séma 


A két tábla közötti kapcsolat leírására XSD key és keyref elemeket 
generál a szerkesztő, amelyek kijelölik a CategoryID-n keresztüli 
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kapcsolódást. Ami számomra furcsa (bizonyára én vagyok az ügyet- 
len, nem a Visual Studio), hogy a Products tábla CategoryID elemé- 
re létrehozott egy XSD keyt, mintha az egy elsődleges kulcs lenne. 
Erről persze szó sincs, ezért azt ki is töröltem. A két alaptábla ID 
elemeire generált kulcsokat átneveztem, és a kapcsolatot leíró 
keyrefet is ennek megfelelően módosítottam. Hiába na, a kézi mun- 
ka gyönyöre. Előállt az alábbi kapcsolatot leíró sémarészlet: 


£xs:unigue name-"Categorykey" 
msdata:PrimaryKey-"true"2 
£xs:selector xpath-".//mstns:Categories" /2 
£€xs:field xpath-"mstns:CategoryID" /2 
£€/xs:unigue2 
£xs:unigue name-"ProductKey" 
msdata:PrimaryKey-"true"2 
£xs:selector xpath-".//mstns:Products" /2 
£xs:field xpath-"mstns:ProductID" /2 
£/xs:unigue2 
€xs:keyref name-"CategoriesProducts" 
refer-"CategoryKey"2 
£xs:selector xpath-".//mstns:Products" /2 
£xs:field xpath-"mstns:CategoryID" /2 
£/xs:keyref2 


Hogyan lesz az xml sémából típusos DataSet? Az xsd.exe segít- 
ségével a következő módon: 


xsd.exe /d TermKkat.xsd 


Az xsd.exe generál egy TermKat.cs Ctt nyelvű forráskódot, amely- 
ben egy hamisítatlan, erősen típusos DataSet-ből származó osz- 
tály kódja található. Ugyanezt megtehetjük a Visual Studio-ban 
is, a Schema menü Generate DataSet paranccsal (a háttérben ott 
is az xsd.exe hívódik meg). A VS nagy előnye, hogy az xsd módo- 
sításakor a háttér DataSet osztály azonnal újragenerálódik. 

A generált DataSet-et le kell fordítanunk a használathoz. Ho- 
gyan lehet feltölteni a két forrástáblával a DataSet-ünket? Egy- 
szerűen létrehozunk két DataAdaptert a megfelelő lekérdezések- 
kel, és mindkettővel feltöltetjük ugyanazt a saját típusos Data- 
Set-et (TermekKatalogus). 


//DataAdapter felépítése a termékekhez 
SalDataAdapter aProd - new SglDataAdapter( 

b "SELECT $§ FROM Products", c); 
//DataAdapter felépítése a kategóriákhoz 
SgiDataAdapter aCat - new SgliDataAdapter( 

b "SELECT $ FROM Categories", c) 


TermekKatalogus ds - new TermekKkatalogust( ); 
//Fontos a feltöltési sorrend, már működik az 
//idegenkulcs! 

aCat.Fill(ds); 

aProd.Fill(ds); 


folytatjuk... 
Soczó Zsolt 
Zsolt.Soczo (onetacademia.net 
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Zárolás, livelock, 


deadlock 


Az SOL Server zárairól lapunk 2001 márciusi számában már olvashattak Soczó Zsolt 
tollából (28. oldal, Transact SOL VI. rész). Végigvette a zárak típusait, 

a tranzakcióizolációs szinteket, majd a cikk végén könnyelműen megígérte, 

hogy legközelebb a deadlock következik. Még egy év sem telt el, s íme a folytatás. 


Mivel azonban mégiscsak eltelt 11 hónap, bátorkodom saját 
szavaimmal ismét feleleveníteni a zárolást, mert anélkül nincs 
halálos ölelés! 


I. rész, elmélet: zárak 

A komoly, adatbázismotoros adatkezelő rendszerek mindegyike 
rendelkezik tranzakciókezelő, és a párhuzamos tranzakciók adat- 
módosításainak elkülönítésére szolgáló beépített rendszerrel. A 
megoldási módszerek tekintetében közel sem egységesek a piac 
versengő termékei - az SOL Server például zárolást használ a 
módosítás alatt álló rekordok védelmére. 

Ha megpróbálunk áthatolni e védelmen, ellenállásba ütközünk: az 
SOL Server megvéd minket attól a szerencsétlenségtől, hogy nem 
végleges, félkész adatokat olvassunk. Ilyenkor várnunk kell a zár fel- 
szabadulásáig. Vannak esetek, amikor ez a várakozás reménytelen. 

Ha megpróbáljuk józan paraszti ésszel megállapítani, hogy mi 
legyen a zárolás alapegysége, arra juthatunk, hogy elegendő 
csupán az éppen módosítás alatt álló rekord megváltozó mező- 
jét hozzáférhetetlenné tenni. Mert hiszen minek is lefoglalni 
egy teljes rekord összes mezőjét (név, cím stb.), ha a felhaszná- 
ló most csak a személyi számot és a születési évet módosítja? 

Ez a gondolatmenet helyes ugyan, de iszonyatosan ,drága". Az 
adatbáziskezelő minden egyes zárolásért memóriával (meg kell je- 
gyeznie, hogy mit fogunk módosítani) és processzoridővel (a záro- 
lást nem hardveresen oldjuk meg ugyebár) fizet. Természetesen mi- 
nél több a lock, annál több erőforrást kell e rendszer fenntartásá- 
ra fordítani. A magas erőforrásigény miatt az ős SOL Serverben 
(6.5-ig bezárólag) a legkisebb zárolható egység a lap (page) volt. 
Az akkori 2 kb-os lapokra átlagosan 50-100 rekord fért, így egyet- 
len sor módosítása miatt kényszerűen még további 49-99 sort fog- 
tunk meg. Volt is rengeteg olyan alkalmazás, mely csak úgy dobál- 
ta magából a deadlockokat, és ütemesen hajigálta vissza a 
tranzakciókat a megdöbbent felhasználónak. Az SOL Server fel- 
használói és fejlesztői új megoldást követeltek Redmondtól. 

A 7.0-s változatban a lapméretet 8 kb-ra növelték, és ha a zá- 
rolási rendszert változatlanul hagyták volna, s mind a mai na- 
pig egész lapokat kellene lefogni, most bizony 200-400 rekor- 
dot zárolnánk feleslegesen egyetlen sor módosítása miatt. A he- 
tes változat óta szerencsére a legkisebb zárolható egység a re- 
kord - de ne higyjük, hogy ez minden alkalmazásfejlesztési és 
tervezési hibát megold! Deadlock mindig lesz! 


A zárak típusai 
,sSzaporodjatok, és sokasodjatok!" 


A zárak típusai hatókör, vagy , méret" szerint 


Vegyünk egy adatmódosító tranzakciót: 
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UPDATE vevok SET cegnev-"NetAcademia" 


Ha ezt ráeresztjük a partneradatbázisunkra, meghökkentő ered- 
ményt kapunk: az összes vevőnk neve NetAcademia-ra változik. 
Kellett volna egy WHERE feltétel, de lemaradt. Most vonatkoztas- 
sunk el e módosítás adatbázisgyilkoló eredményétől, és koncent- 
ráljunk kizárólag arra, mi is történik a végrehajtás során. Végig- 
futunk a táblán, és módosításra kerül az összes vevő cégneve. Ha 
minden egyes rekordot külön-külön zárolna az SOL Server, akkor 
egy-egy 8k-s lapon többszáz egyedi fogd-meg-ereszd-el történ- 
ne, amelynek végrehajtási ideje vetekedne az érdemi munka, a 
módosítás idejével. Az SOL Server azonban résen van: ha egy la- 
pon túl sok egyedi rekordot kellene zárolni, akkor visszatér a jó 
öreg page lockhoz, és egy akkorddal lefogja a lap összes sorát, 
módosít, majd elengedi a lapot. Ez az eljárás többször gyorsabb 
lehet, mintha minden egyes soron külön-külön vacakolna a la- 
kattal. A folyamatot lock escalationnak hívják, és némiképp pa- 
raméterezhető az sp. configure tárolt eljárás segítségével (kü- 
szöbszámokat és százalékokat lehet állítgatni, de ne babráljuk) . 
A fenti utasításból és gondolatmenetből kiolvasható, hogy az SOL 
Server automatikusan teszi fel és veszi le a megfelelő zárakat a 
tranzakciók futtatása során. Optimizer Hintekkel a működés befo- 
lyásolható ugyan, de általános, és sokat ismételt aranyszabályként 
jegyezzük meg: Optimizer Hintet alkalmazásokba bevarrni TILOS! 
Ha egy tranzakció netántalán egy teljes táblát érint, akkor - az 
eszkaláció következő lépéseként - az SOL Server a sok-sok egye- 
di page lockot lecserél(het)i táblaszintű zárolásra, mert ezzel 
megintcsak értékes erőforrások szabadulnak fel. Ezernyi page 
lock helyett egyetlen table lock - erőforrásspórolás a köbön. 


A zárak típusai a felhasználás módja szerint 

Ha a zárolási rendszerről beszélünk, óhatatlanul felmerül a gon- 
dolat: mely műveletek során van szükség zárak használatára? Az 
UPDATE, INSERT és DELETE műveleteknél egyértelmű a válasz: 
adatmódosítás történik, tehát kell a lakat. Ilyenkor az SOL 
Server úgynevezett exclusive lockot, kizárólagos felhasználásra 
jogosító zárat tesz az érintett sorra/lapra/táblára (az eszkaláció 
szerint), s azt a tranzakció végéig fenn is tartja - más még csak 
nem is olvashatja a megbűvölés alatt álló adatokat. 

De SELECT esetén kell-e zárolni? Ilyenkor adatmódosítás nyilván- 
valóan nem történik - minek ide zár? Ilyen esetben a zárolás cél- 
ja, hogy lehetetlenné tegye azon adatok módosítását, melyeket 
éppen olvasunk. Az SOL Serverben alapértelmezésben minden ol- 
vasás konzisztens adatokat, lezárt tranzakciók utáni állapotot ad 
vissza. Erre azért képes, mert minden olvasott sorra/lapra/táblá- 
ra (az eszkaláció szerint) úgynevezett shared lockot, megosztott 
zárolást helyez. Azért megosztott, mert egy így zárolt objektum- 
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Zárolás, 


Ja 


ra tetszőleges számú további olvasó csimpaszkodhat, 

és olvashatja párhuzamosan a többiekkel. 
A végeredmény: egy adatot egyszerre tetszőleges 
számú folyamat olvashat, de csak egyetlenegy írhatja. 
Ha felütjük a Books Online megfelelő fejezetét, rábukkan- 
hatunk a zárak kompatibilitási táblázatára. Ez megmutatja, 
hogy ha egy rekordon ilyen-olyan zár van, milyen további zárak 

pakolhatók rá akadálytalanul. 












Új zár 


shared update exclusive 





shared 
update 
exclusive 





Jelenlegi zár 








Csillag jelöli a táblázatban azokat a zárkombinációkat, ahol egy 
meglévő x zárra rá lehet tenni egy y zárat. Ebből kiolvasható, 
hogy a shared és az exclusive lock nem kompatibilis egymással, 
nem pakolható egyik a másikra. Egy módosító tranzakciónak ki 
kell várnia, hogy az összes olvasó eltakarodjék az útból. Azonban 
gátat kell tudnunk szabni az ,olvasóközönségnek", mert egy ép- 
pen olvasott adatra a fenti táblázat szerint shared lockot akárki, 
akármikor ki tud adni, a módosításra váró tranzakció pedig csak 
várna, hogy tiszta legyen a terep, de hiába, mert az új olvasók 
csak jönnek és jönnek. Az update lock feladata az ,álljon meg a 
menet!" jelzése az olvasó folyamatok felé. Ez ugyanis rátehető a 
shared lockokra, de őrá már sharedet pakolni nem lehet. Olyan, 
mint az UNO kártyában a kérőlap: mostantól csak adott kártya- 
lapot lehet tenni, mégpedig exclusive lock feliratút. Akinek 
shared van a kezében, az mostantól nem teheti le a lapját. Az 
update lock nevével ellentétben még nem jelent adatmódosítást, 
csak a szándék jelzésére való. Amikor ugyanis ,kijátsszuk" ezt a 
lapot, még bőven van a halomban alatta shared lock, melyek idő- 
vel eltakarodnak - új azonban már nem lesz! Így az update lock 
jelenléte egy soron/lapon/táblán bizony várakozást jelent: arra 
várunk, hogy végre mindenki eltűnjön, és átállhassunk exclusive 
zárolásra, s a módosítás valóban bekövetkezhessen. 


A livelock és az új vasunk 

A zárolási folyamat eddigi ismertetéséből kitűnik, hogy ha a sze- 
rencse, vagy a rossz tervezés úgy hozza, az adatmódosítások bizony 
jelentős késlekedést szenvedhetnek, amitől az alkalmazás maga is 
lelassul, és - Magyarországon vagyunk - a vezérigazgató egy idő 
múlva engedélyt ad új, nagyobb vas beszerzésére. (Még véletlenül 
sem gyanakszik a fejlesztőre.) Hisz nyilvánvaló, hogy a régi pécé 
nem bírja a terhelést! A sors különös fintorának tűnik ezek után, 
hogy az új vas sem bírja. Egyértelmű: rossz az SOL Server, kapita- 
(ista-globalista-monopolista a Microsoft és hülye a Bill Gates. 

Meg tudom érteni a gondolatmenetüket: x raktáralkalmazás fél 
éve úgy futott, mint a kisangyal, de azóta belevittünk még ezer 
(!) tételt, felvettünk négy új alkalmazottat, és jól látható mó- 
don ez kifektette a régi, Pentium III 450-es kiszolgálót. Bárho- 
gyan is logikusnak tűnik az okfejtés, én az ilyen okoskodás hal- 
latán sírógörcsöt kapok: ezer rekord és négy júzer kiüt egy SOL 
Servert? Tessenek belegondolni: amikor 486 DX4-100 volt a 
csúcspécé, SOL Server 6.0-val többezer felhasználós, gigabájtos 
adatbázisrendszerek készültek! 


Axióma 

Magyarországon nincs az az adatbázisméret, ami megfektet- 
ne egy SOL Servert, és nincs az a kereskedelmi forgalomban 
kapható PC, ami ne lenne elég erős bármilyen feladatra! 
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Ez talán egy kicsit sarkított véleménynek tűnik, de van ennél 
durvább is: 


128 MB RAM, 10 GB HDD, PIII 800 mindenre elég 


(Bill Gates után szabadon :-) 

Gigabájtok? Ugyan már! Kétszáz felhasználó? Hol, melyik válla- 
latnál van akár csak feleennyi SOL user? 

Az SOL Server teljesítményproblémák 1759-ban hibás ter- 
vezésre vezethetők vissza. 


"Ta SOL Server Enterprise Manager - [Console RootWMicrosoft SOL ServersiSOL Sei 


"fh File Action View — Tools Window Help 
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A Ej] Microsoft SOL Servers 
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E CI Databases 
63 CI Data Transformation Ser 
5 CI Management 
B 23 SOL Server Agent 
Backup 
A ly current Activity - 201 
Process Info 
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spid 52 53 
(Blocked By (Blocking) 
53) 


(x- éj] Locks / Object 


5 Az Enterprise Managerben jól látható, hogy melyik folyamat 
vár, és melyik okozza a várakozást (felkiáltójellel jelölve) 


A legváltozatosabb fejlesztői baklövések miatt lassulnak be az 

alkalmazások. Vegyünk néhány, életből ellesett példát: 

-b Az ügyféloldali alkalmazás fejlesztője hadilábon áll az SOL 

nyelvvel, ezért mindenhova a legegyszerűbb lekérdezést írja 

az ADO kommandokba: SELECT " FROM TABLA. EL se hinnék, 
hogy ez milyen gyakori eset. Hány sor, és hány oszlop megy 
át a munkaállomásokra? Ugye mind? Milyen index gyorsítja 

ezt a lekérdezést? Semmilyen. Kár indexelni. Az SOL Server a 

teljes tábla lekérdezése miatt table lockra eszkalál, nem fog 

pepecselni egyedi sorszintű zárolással. Ahogy növekszik a 

tábla, úgy válik egyre hosszabbá az az idő, amíg ezen a táb- 

lán táblaszintű shared lock van. A módosításra váró tranzak- 
ciók holtideje egyenletesen növekszik, merthogy indexhasz- 
nálat híján table Scan , stratégiával" csoszog végig az SOL 

Server a táblán. Kétszerannyi rekord? Kétszerakkora idő! 

Háromszorannyi adat? Háromszorannyi idő! s 

Eseményvezérelt ügyfélalkalmazásunkban ráakaszkodunk az 

egyik tetszetős eventre (mondjuk: OnMouseMove), és itt el- 

helyezünk egy csinos kis SELECT-et. Hányszor fog lefutni? X- 

nél többször, az már egyszer biztos! shared lock, shared 

lock, shared lock. 

"8 Tranzakció kellős közepén megkérdezzük a felhasználót egy 
párbeszédpanelben, hogy komolyan gondolta-e. Kattintson 
az igenre, ha igen. A felhasználó azonban a kávéautomatát 
támasztja: exclusive lock a végtelenségig. Eközben nem le- 
het eladni, mert a mocskos SOL Server nem mutatja meg a 
pultnál, hogy hány darab van a vevő által kért fittingből. 

"8 További furfangos lassító módszerek léteznek az indexek meg- 
spórolásától kezdve a tempdb in ram őrült opció beállításáig. 


A zárak típusai a felhasználás szándéka szerint 

Az alcím az eredeti angol kifejezés (intent lock) fordítása, de né- 
miképp félrevezető. Az Intent lockok ugyanis segédfunkciót töl- 
tenek be az SOL Serverben. Vegyünk egy példát. Néhány tranzak- 
ció éppen módosít egy-egy sort, emiatt sorszintű exclusive 
lockokat használnak. Egy másik alkalmazás egy SELECT " utasí- 
tással lekérdezi a teljes táblát, tehát táblaszintű shared lockot 
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használna. Hogyan dönthető el minimális idő alatt, hogy az 
egész táblára rátehető-e a shared lock? A helyzet a következő: a 
fiúk a bányában (sorszinten) dolgoznak, de nekünk a bánya be- 
járatánál állva el kell tudnunk dönteni, hogy van-e valaki oda- 
lenn, mert el szeretnénk árasztani vízzel. Ha óvatlanok vagyunk, 
megfulladhatnak a vájárok. Ha lemegyünk körülnézni, végig kell 
járnunk az összes járatot, hogy meggyőződhessünk róla: senki 
sem dolgozik. Idő, értékes idő! A bejárós stratégia további hát- 
ránya, hogy miközben odalenn mászkálunk, és hahózunk, újabb 
vájárok szállhatnak be a liftbe, és jöhetnek le. Így sohasem vég- 
zünk! Ehelyett inkább hozzunk olyan szabályt, hogy aki lemegy, 
az egy zászlócskát tűz a bejárathoz, amit kifelé jövet eltávolít 
onnan. Így egyetlen pillantással eldönthető, hogy mehet-e a víz. 
A zászlócska neve: intent lock. Különböző típusai vannak annak 
megfelelően, hogy a leszálló személy csak nézelődni megy 
(munkavezető, shared lock), vagy dolgozni is fog (vájár, exclusi- 
ve lock). A bányászos példánál annyival bonyolultabb a valóság, 
hogy jelzőzászlót nemcsak a bejárathoz (táblaszinten) kell ten- 
ni, hanem lapszinten is, hogy a 8 kilobájtos lapok zárolásáról is 
dönteni lehessen az egyes sorok átvizsgálása nélkül. 


Tranzakciók és izolációs szintek 

Az izolációs szintek arról szólnak, hogy egy alkalmazás mennyi- 
re szeretné, hogy az általa használt adatok a tranzakciók végéig 
változatlanok maradjanak. Minél , változatlanabb" adatra van 
szükség, annál erősebben kell markolni mindent, amit haszná- 
lunk. Alapértelmezésben (Read committed) a tranzakciók során 
kiadott exclusive lockok megmaradnak, de az olvasott rekordok 
shared lockjai menet közben elpárolognak, hogy amit mi csak 
olvasunk, azt más szabadon módosíthassa. Repeatable read ese- 
tén már a shared lockok is kitartanak a tranzakció végéig: bár- 
mi, amit olvasunk, az garantáltan változatlan marad tranzak- 
ciónk végéig. Serializable izolációs szinten még az indexfa ele- 
mei is zárolásra kerülnek, hogy nehogy hasonló rekordok buk- 
kanjanak fel, mialatt mi dolgozunk. 

Ez ügyben mégiscsak a tavaly márciusi szám elolvasását javas- 
lom, a 31. oldaltól két teljes oldalon át az izolációs szintek 
elemzését találjuk. Térjünk rá a halálra. 


II. rész, gyakorlat: a halálos ölelés 

Amikor két (vagy több) tranzakció úgy kerül várakozási állapotba, 
hogy kölcsönösen egymás erőforrásaira várnak, a konfliktus felold- 
hatatlanná válik: egyik sem engedi, ami az övé, ezzel nem hagyja a 
másikat sem továbbfutni. Ezt a zárolási esetet az SOL Server szeren- 
csére éppúgy észreveszi, mint a fent mutatott live lockot, és pontot 
tesz az ügy végére: az egyik tranzakciót visszagörgeti (rollback). 
Ha kettőnél több folyamat csimpaszkodik egymást akadályozó mó- 
don egymásba, csodálatos deadlock fürtök alakulhatnak ki. Ilyen 
esetben rendkívül nehéz utólag megállapítani, hogy hová implemen- 
táltuk azt a tervezési hibát, ami miatt megáll egy tucat tranzakció. 
Célszerű már előre olyan adatbázistevet és alkalmazást készíteni, 
mely minimálisra csökkenti a deadlockok kialakulásának esélyét. Van 
egy-két ökölszabály, melyekre érdemes figyelni, ezek közül a legfon- 
tosabb, hogy tranzakcióink mindig ugyanabban a sorrendben nyúlja- 
nak hozzá a táblákhoz, így eleve nem alakulhat ki olyan helyzet, mint 
az alábbi ábrán, ahol az egyik folyamat az A táblát fogja, és B eléré- 
sére vár, míg a másik folyamat B-t zárolja, és A-ra vár. 
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TableA TableB 


A A 
B H 
8. e 


Cas ra 


a e 


a Két tranzakció egymás zárolt erőforrására vár. Az egyik- 
nek el kell pusztulnia, hogy a másik tovább élhessen! 


Hamarosan látni fogjuk, hogy a fenti ökölszabály nem igazán je- 
lent megoldást, mert bizony egyetlen kétsoros táblán is létrejö- 
het deadlock - csak ,megfelelő" eljárás kell hozzá! 


Melyiket vonjuk vissza? 

Fontos kérdés, hogy - ha már egyszer megtörtént a baj - vajon 
az összeakaszkodott tranzakciók közül melyikre mondjunk halá- 
los ítéletet. Ezt a folyamatok fontossága alapján maga az SOL 
Server eldönteni nem tudja, hisz nem érti, mit veszítünk egy- 
egy adatmódosítás visszavonásával. Alapértelmezésben az SOL 
Server-féle költség dönt: amelyik ,olcsóbban" visszavonható, az 
fog meghalni. Még pontosabban: amelyik kevesebb tranzakció- 
napló bejegyzést tett, az lesz az áldozat. 

Ezt a működést némiképp szabályozhatjuk a 


SET DEADLOCK PRIORITY ( LOW ! NORMAL) 


utasítás segítségével, bár a parancs szintaxisából kiderül, hogy 
pont az hiányzik, ami kellene: a magas túlélési prioritás beállítása! 


Felkészülés a halálra 
Most néhány sorban készítünk egy tesztadatbázist, melyben 
szabadon lehet majd összeakasztani felhasználókat egymással. 
Jelentkezzünk be az SOL Serverre egy rendszeradmin erősségű 
felhasználóval, majd: 


create database semmi 


Ez a parancs egy ,semmi" nevű adatbázist készít. (Default mé- 
ret, fájl stb. stb.). Most átállunk erre az újdonsült adatbázisra: 


use semmi 

Kell egy tesztfelhasználó: 

sp.addlogin "senki" 

... akit beengedünk a ,semmi" adatbázisba: 

sp.adduser "senki" 

Ezután létrehozunk egy nagyon egyszerű, két mezőből álló táblát: 
create table vevok ( 


id int, 
name varchar(22) 
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...melybe beszúrunk két sornyi adatot: 


Már majdnem készen vagyunk. Indexeljük le a ,name" mezőt, 
mert azt gyakran használjuk keresésekben: 


insert vevok values(l, "NetAcademia") 


insert vevok values(2, " iNetCom") 


create index nameindex on vevok(name) 


Jogot adunk , senki"-nek a vevok tábla használatához: Mostantól el kell szakadnunk a kéthasábos formától, mert két 


grant select, 


€-gpI 


1. tranzakció lépése 
begin tran 


párhuzamosan futó tranzakció lépéseit fogom ábrázolni egymás 


update on vevok to senki mellett. A két folyamat betűről betűre ugyanaz: ugyanannak az 


ügyfélprogramnak két példánya akad össze egymással. Kérem, 
senki ne akadjon fenn a kód ostobaságán. Az élet szülte! 


2. tranzakció lépése ] Megjegyzés 
begin tran Mindkét folyamat elindul 





update vevok set 
name-Eniac Hungary 
Bt." where id-1 


Az első folyamat exclusive lockot helyez az első sorra. Simán lefut. 
A lock ottmarad a tranzakció végéig! 





update vevok set A második folyamat exclusive lockot helyez a második sorra. 
name-Eniac Hungary ] Akadálytalanul lefut, lock marad! 
Bt." where id-2 





select " from vevok 


Az első folyamat kíváncsi a végeredményre, ezért leválogatja a teljes 
táblát. Leválogat-ná. Ha nem lenne zárolva a tábal második sora. 
Livelock, földgömb forog. 





select " from vevok Nesze neked, mégegy select. Természetesen ez is elakad, és 
reménytelenül vár az első folyamat végére, mert az viszont ránk vár. 
Deadlock. 








Server: Msg 2205, Level 23, State 50, Line 1 
Transaction (Process ID 52) was deadlocked on (lock) resources with another process and has been 
chosen as the deadlock victim. Rerun the transaction. 








A két folyamat közül az egyik visszavonódik (rollback). A fenti 
esetben mindkettő ugyanannyit dolgozott, így véletlenszerűen 
dől el, melyik haljon meg. Az egyik mindenesetre áldozatául 
(victim) esik az SOL Server kemény akaratának. Alkalmazásaink- 
ban mindig figyeljünk a 1205-ös hibakódra. Ha ez felbukkan, tö- 
rődjünk vele, mert bizony a tranzakciónk nem futott le! 


A deadlock okainak felderítése 
Talán az egyik legnehezebb adatbázistuningolási feladat a halá- 
los ölelések kivédése, mert sok esetben meghatározhatatlan 
időközönként jön egy-egy. Ilyenkor természetesen senki nem áll 
készenlétben, így elkapni sem lehet. Olyan megoldásra van te- 
hát szükségünk, amely hosszú időn át figyeli a deadlockokat, és 
naplót ír, ha megint beesett egy. Ezt a feladatot az SOL Server 
maga végzi. Ha az SOLSERVR.EXE-t nem szolgáltatásként (ser- 
vice), hanem parancssorból indítjuk, egyrész látni fogjuk egy 
"DOS" ablakban, hogy mit művel, másrészt különböző parancs- 
sori kapcsolókkal módosíthatjuk a futását. A -T kapcsolóval 
nyomkövetési (trace) üzemmódba kapcsolhatjuk. Indítsuk így: 
SOLSERVR -T 1204 
Ekkor az SOL Server minden deadlock információt kiír a képer- 
nyőre, beleértve az összeakaszkodó folyamatok azonosítóit és a 
vetekedő SOL parancsokat is! 
Jó nyomozást! 
Fóti Marcell 
marcellfonetacademia.net 
MCDBA 
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— itt a végleges .NET 


Framework! 


2001 október közepétől a Netacademia Kft üzemelteti Magyarország egyik legnagyobb 
letöltőközpontját. A Microsoft Magyarország megbízásából elkészült oldalak az 

eddig megszokott tartalommal, de eltérő formában jelentkeznek. 

Az innen letölthető programok közül csemegézünk ebben a rovatban. 


.NET Framework Software Development Kit 

bálgattuk az új technológiát, ismerkedtünk előnyeivel és hátrá- 

nyaival. Nyomonkövethettük, hogy válnak egyre kidolgozottab- 

bá, teljesebbé a névterek, az elérhető objektumok. 

Január közepén végre annak örülhettünk, hogy az újonnan 

kiadott verzió már nem egy újabb béta, hanem az első teljes 

verziót tarthattuk kezünkben. 

Ebben a cikkben a végleges verzióval foglalkozunk. Megtudhat- 

juk milyen rendszerkövetelményei vannak a .Net Frameworknek, 

milyen eszközök érhetők el a telepítés után, és milyen változá- 

sokon esett át a Beta2 óta. 

A .NET Framework SDK a következő platformokra telepíthető: 

"0 Windows 2000 a legutolsó javítócsomaggal 

"8 Windows XP 

"Windows NT 4.0. Ha ez a platform áll a rendelkezésére, akkor 
rendelkezni kell a Windows NT 4.0 SP6a javítócsomaggal is. 

Szoftverek közül pedig az alábbiakra van szükség: 

0 Internet Explorer 5.01 vagy ennél frissebb verzió 

8 Internet Information Server 

0 a Microsoft Data Access Component 2.6 követelmény, de aján- 
lott az MDAC 2.7. 

A .NET Framework részét képezi az ASP.NET platform, mely olyan 

webalkalmazások készítését teszi lehetővé, amelyek a Common 

Language Runtime (CLR) minden előnyét, például a biztonságos 

típushasználatot, az öröklődést, a verziózást kihasználják. 

Ebben a rendszerben már elkülöníthető a design és a progra- 

mozás. Külön fájlokban tárolhatók az oldalt kiszolgáló program- 

kódok, melyek megírásához többféle nyelvet is választhatunk 

(Visual Basic .NET, C$t, Jscript .NET) . 

Az alkalmazások fejlesztéséhez használhatunk különböző HTML 

szerkesztőket, vagy akár Notepad-ot is, de a Microsoft Visual 

Studio .NET programcsomagot is az összes eszközével. 

Természetesen ez utóbbi nem ingyenes, viszont tartalmazza 

.NET Framework-ot, valamint minden olyan eszközt, amire a fej- 

lesztéshez szükségünk lehet. 

Ám azok se keseredjenek el, akik az ingyenesen letölthető .NET 

Framework SDK-t választják és nem rendelkeznek Microsoft Visual 

Studio .NET-tel. Amire szükségük lehet, így is megtalálják. Lehet, 

hogy így kicsit tovább tart a fejlesztés, viszont beleláthatnak a 

.NET lelkivilágába, és olyan részletek is feltárulhatnak előttünk, 

amelyeket a Visual Studio varázslói egyébként elrejtenének. 

Jó tudni, ha a .NET Framework SDK telepítése előtt nincs telepít- 

ve rendszerünkre IIS, akkor az ASP.NET alkalmazások - nyilván - 

nem futnak. Ha utólag történik meg az IIS telepítése, akkor kéz- 

zel kell regisztrálnunk az Aspnet. isapi.dll fájlt a Regsvr32.exe se- 
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gítségével. Valamint minden egyes rendszerfrissítés után a .NET 
Framework-öt javítanunk kell. Ezt megtehetjük a Control Panel / 
Add or Remove Programs / Microsoft .NET Framework SDK -nál a 
Click here for support information linkre kattintva. Ez a hivatko- 
zás egy repair.htm fájlra mutat a telepített .NET Framework 
megfelő verziókönyvtárában. Ha ez nem található, akkor a n:Yyse- 
tup.exe /t:Yotemp9o /c:"msiexec.exe /fvecms "otemp9olmetfxs- 
dk.msi" utasítást kell beírnunk egy parancssorba. 
Ez után a kis kitérő után nézzünk néhány olyan eszközt, amely 
a rendelkezésünkre áll a .NET Framework telepítése után. 
Assembly Cache Viewer (Shfusion.díll): A global assembly 
cache-t lehet vele nézegetni, illetve szerkeszteni. 
Assembly Registration Tool (Regasm.exe) : egy assembly-n be- 
lüli metaadatokat olvassa ki és elvégzi a szükséges bejegyzése- 
ket a registry-ben, amely lehetővé teszi, hogy COM kliensek .Net 
Framework osztályokat használjanak. 
Assembly Binding Log Viewer (Fuslogvw.exe) : a hibás assembly- 
kötések okát mutatja meg. E segítségével megtudhatjuk, miért 
nem talál meg egy assemblyt futás közben a .NET Framework. 
.NET Framework Configuration Tool (Mscorcfg.msc): egy Mic- 
rosoft Management Console-t nyit, melyen keresztül menedzsel- 
hetjük a Global Assambly Cache-ben lévő assemblyket, a kód- 
hozzáférési védelmi beállításokat, a remote service-ket. 
Microsoft CLR Debugger (DbgCLR.exe): grafikus felülettel ren- 
delkező (vissza)fordító, amely segít a fejlesztéskor fellépő hibák 
megtalálásában és javításában. 
Runtime Debugger (Cordbg.exe): parancssori hibakereső, 
amely segít a hibák azonosításában és javításában. 
(A fenti két fordító valamelyikét vagy a Systems. Diagnostics osz- 
tály függvényeit kell használnunk akkor, ha nem rendelkezünk a 
Visual Studio .Net-tel. ) 
A Code Access Security Policy Tool (Caspol.exe): segítségével 
meghatározhatjuk és módosíthatjuk a kódhozzáférések bizton- 
sági beállításait a gép, felhasználó illetve vállalat szintjén. 
Ezeken kívül persze nagyon sok hasznos dolgot találhatunk még. 
Végül az egyik újdonság a .NET Framework-ben a Beta2-höz ké- 
pest: míg az előző verzióban az ASP.NET System-ként futott, ad- 
dig a végleges verzióban már saját account-tal (ASPNET) rendel- 
kezik. Így szabályozhatjuk, hogy milyen jogosultságokkal ren- 
delkezzen .Net webünk. ; 
Borsi Katalin 
bobo onetacademia.net 


A cikkben szereplő URL-ek: 


[11] http://msdownload.netacademia.net 
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K1: A merevlemezek elérési sebessége jelentősen lassítja a számí- 
tógépek összteljesítményét. A teljesítmény növelhető a 
Windowsba épített RAID eszközökkel. Mi lehet az oka, hogy néha 
mégsem érjük el a kívánt gyorsulást? 


K2: 2 db 40 GB-os merevlemezt szerettem volna össze stripe-olni 
(magyarul csíkkészletet létrehozni) és érdekes dolog történt. Mind- 
kettő FAT32-re volt formázva, egyenként jól működtek, de a szoft- 
veres stripe nem volt sikeres, a hibaüzenet Volume size too big" 
volt. Kikísérleteztem, hogy FAT32 fájlrendszerrel a maximális mé- 
ret partíciónként 16384 MB lehet. Ennél nagyobb partíciókon ,,ter- 
mészetesen" NTFS fájlrendszernek kell lennie. Ennek nem igazán 
látom okát, mivel a FAT32 fájlrendszer Windows 9x alatt ennél lé- 
nyegesen nagyobb területet tud egy darabban kezelni. Nem lenne 
egyébként semmi bajom az NTFS-sel, csupán annyi, hogy nagyon 
lassú, a két merevlemezt meg éppen azért akartam össze stripe- 
olni, hogy jó gyors elérést kapjak. Így, hogy NTFS van rajtuk, még 
együtt sincsenek olyan fürgék, mint egyenként FAT32-vel. 


V1: a FAT32 és a méret problémája. A válasz a Windows 2000-ben 
keresendő. A Windows 2000 maximálisan 32 GB méretre tud formáz- 
ni FAT32 partíciót (az előre formázott nagyobb méretőt kezeli), így 
volt lehetséges, hogy az összekötött (stripe-ba, más néven RAID 0-ba 
szervezett) merevlemezek egyenként 16 GB-ig, azaz összesen 32 GB- 
ig működtek. Ennek csupán az az oka, hogy a Microsoft szeretné le- 
szoktatni a Windows 2000 felhasználóit a FAT, FAT32 használatáról. 


V2: az NTFS és a stripe sebességéből eredő probléma. Nézzük 
meg mit takar a stripe fogalma! A stripe vagy RAID 0 a merevle- 
mezek paramétereinek javítása érdekében kidolgozott műszaki 
megoldás, a RAID legalacsonyabb szintje. A RAID (Redundant 
Array of Independent Disks) alkalmazásával az adatelérési sebes- 
ség, az adattárolók összefüggő mérete, valamint a magasabb adat- 
biztonsági szint egyaránt növelhető, sőt, hibatőrő rendszer alakít- 
ható ki. A RAID ezeket a tulajdonságokat több merevlemez együt- 
tes alkalmazásával valósítja meg. Attól függően, hogy a kezelését 
hardver vagy szoftver végzi, hardveres vagy szoftveres RAID-ről 
beszélünk. A hardveres RAID speciális eszközöket igényel, alkal- 
mazásuk általában nem függ az operációs rendszerektől. A szoft- 
veres RAID csak olyan operációs rendszereknél alkalmazható, me- 
lyek tartalmazzák ennek támogatását. A Windows NT és a Windows 
2000 tartalmazza a RAID 0,1,5 szintek támogatását. 

A szoftveres RAID a processzor és az I/0 rendszer számára több- 
letterhelést jelent a RAID folyamatos számítási feladatainak kö- 
vetkeztében. Ez a mai GHz közeli processzorok esetében nem 
okoz túlterhelést, de kisebb processzoroknál vagy kiélezett ese- 
tekben problémát okozhat. 

A merevlemezek elhelyezése a csatolókon szintén teljesítmény- 
probléma forrása lehet. Minél több csatolón (SCSI, IDE) helyez- 
zük el a stripe egységeit, annál nagyobb számítási és busztelje- 
sítményt veszünk igénybe. Célszerű tehát a stripe egységeit egy 
vezérlőn elhelyezni. 
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RAID, Windows XP 


Az alkalmazott merevlemezek száma újabb problémát vet fel. A 
merevlemezek számának növelése a rendszer összteljesítményé- 
nek jelentős részét veheti igénybe. Másrészt minél több a me- 
revlemez, annál nagyobb a hibalehetőség. 

Ezekre a problémákra a hardveres RAID vezérlők jó megoldást 
nyújtanak, bár intenzív mentés nélkül a stripe alkalmazása ve- 
szélyes a hibatűrés hiánya miatt. 


Az alábbi lehetőség már az NTFS gyorsítására vonatkozik: 

Ha a naplózási és biztonsági információkra nem tartunk igényt ki- 
Ez olyan esetekben segíthet, ahol nagy a mappák száma egy par- 
tíción. A REGEDT32 elindítása után a HKEY. LOCAL. MACHINEN 
SystemiCurrentControlSetiControlMNFileSystem kulcsot 
kell szerkeszteni. Szerkesztés, érték hozzáadása: 


Név: NtfsDisableLastAccessUpdate 
Adattípus: REG DWORD 
Érték: 1 


K: Feltelepítettem a Windows XP-t, de valamiért eltűnt a mappák 
tulajdonságlapjáról a , Security" oldal, pedig a fájlrendszer ott 
NTFS... és a megosztás is valami nagyon furcsán működik! Mi tör- 
tént? És egyáltalán, mi történik, amikor a fájlmegosztó varázsló 
varázsol? Kérem vissza a régi jól megszokott, átlátható felületet! 


V: A Windows XP alapértelmezésben az úgynevezett , Simple File 
Sharing" (egyszerűsített fájlmegosztás) üzemmódban működik. 
Ilyenkor a felhasználó elől elrejti a fájlok/mappák tulajdonság- 
lapjának , Security" oldalát, a ,Sharing" pedig bizony átalakul 
varázslók gyülekezetévé: 

5 Az ábrán látható oldal a Butított (na jó, Egyszerűsített) 


"Generalf Shaing [web Sharng [[ Customize] 
Local sharing and security 


To share this folder váth other users of this computer 
only. drag it to the Shared Document: folder. 


To make this folder and üs subfolders private so that 
only you have access, select the following check box. 








Network sharing and secusity 
To share this folder with both network users and other 
users of this computer, select the first check box below 
andtype a share name. 


























OK Cancel Apply 


Fájlmegosztás eredménye. A Security fül — jól látható, hogy — 
nem látható 











cHU8S. ÜZ. 


Mielőtt visszaváltanánk hagyományos üzemmódba, azért nézzük 
meg, ezen az oldalon mi mit jelent! A Local sharing and security 
(helyi megosztás és biztonság) mezőben a mappa/fájl helyi, szá- 
mítógépen belüli megosztásának lehetőségét találjuk. A felirat 
tanúsága szerint a fájlt vagy mappát a helyi felhasználók között 
úgy oszthatjuk meg, hogy azt (egészen pontosan annak egy má- 
solatát) bevonszoljuk a Shared Documents mappa alá. 
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19 My Computer 








( Files Stored on This Computer 


1 Shared Documents 


System Tasks 2 
EA view systeminformation 
DJ Addor remove programs 
G change a setting 


TC] eerrmtttséstsamsns 


0 A Shared Documents mappa tartalmát minden helyi fel- 
használó eléri 


A Shared Documents mappa - amit egyébiránt a My Computer ab- 
lakon keresztül érhetünk el - nem más, mint az , All Users" profil 
My Documents mappája - azaz egy mindenki számára elérhető kö- 
zös tárolóhely, a cfelhasználónévass Documents mappa pedig az 
aktuálisan bejelentkezett felhasználó My Documents könyvtára. 
Ha valakit zavar, hogy ezek a mappák (ha az aktuálisan bejelent- 
kezett felhasználó rendszergazdai jogokkal bír, akkor ráadásul min- 
den helyi felhasználó mappája is) megjelennek a My Computer ab- 
lakban, az [1] címről letölthető Windows XP PowerToys részeként 
telepíthető Tweak UI programocska segítségével kikapcsolhatja: 


E My Computer 


9 A Tweak UI segítségével kikapcsolhatjuk a speciális map- 
pák megjelenítését (is) 


Az egyszerűsített fájlmegosztás oldal alsó fele a hálózati 
megosztásra koncentrál (emlékeztetőül ismét a két lehetséges 
választási lehetőség) : 


Network sharing and security 

To share this folder with both network users and other 
JE) users of this computer, select the first check box below 
and type a share name. 























7] Allow network users to change my files 





0 Egyszerűsített fájlmegosztás a hálózaton 


A felső opció önmagáért beszél; bekattintásával megosztjuk a 
mappát a többi felhasználó részére. Ilyenkor a varázsló felveszi 
az Everyone csoportot mind a mappa NTFS jogai közé, mind a 
megosztás jogosultságlistájába. Hogy milyen jogosultságokkal, 
azt az alsó pipával határozhatjuk meg (,Allow network users to 
change my files"): 
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Everyone jog 
Lokális NTFS 
Megosztás 


[71 Alosi netescik users CI állva network users 
Modify Read 8. Execute 
Full Control Read ] 
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5 A varázsló által különféle üzemmódokban a megosz- 
tás illetve a mappa NTFS jogosultságlistájához hozzáadott 
Everyone jogosultságok táblázata 


Ha valakinek ez nem megfelelő, az egyszerűsített fáljmegosztást 
(a Windows XP Professional-ban) egyetlen jól irányzott kattin- 
tással kikapcsolhatja a mappák tulajdonságlapjának View olda- 
lán (jól tesszük, ha a beállítást a rendszer összes mappájára ér- 
vényesítjük). Ehhez a listában töröljük a ,Use simple file 
sharing (Recommended)" opció előtt álló pipát! 


Folder Options 
[General View  (Fie Types ][ Offine Füles] 
Folder vieves 


You can apply the view (such as Detais or Tiles) that 
ou ate using for this folder to all folders. 


Apply to Al Folders Reset Al Folders 


Advanced settings 

Launch folder windows in a separate process 

3 Managing paits of Web pages and folders 

0 Show and manage the pair as a single file 

O Show both parts and manage them indívidualy 

O Show both parts but manage as a single file 

[7] Remember each folders view settings 

CT Restore previous folder windows at logon 

Show Control Panel in My Computer 

how enciypled or compressed NTFS files ín color 
jplion for folder and desktop items 



































5 Az egyszerűsített fájlmegosztás letiltása egyetlen kattin- 
tás - ha tudjuk, mit keressünk! 


K: Eddig más operációs rendszerem volt, és nagyszerűen működött 
minden. Amióta feltelepítettem a Windows XP-t, bizonyos dolgo- 
kat nem érek el az Interneten. Érdekes, hogy teljesen zökkenő- 
mentesen működik a web-elérés, levelet is tudok küldeni-fogadni, 
de például az IRC már nem hajlandó működni. Vajon miért? 


V: Előfordulhat, hogy a Windows XP beépített tűzfala, az 
Internet Connection Firewall (ICF) van a háttérben. Az Internet- 
csatlakozás varázsló ugyanis a kapcsolat ikonjának létrehozása- 
kor alapértelmezésben felajánlja az ICF bekapcsolását. Ha , fi- 
gyelmetlenek" vagyunk, ez bekapcsolva maradhat. Ha az ICF ak- 
tív, minden kifelé induló kapcsolatot engedélyez (ezért működ- 
het zavartalanul a webezés, levelezés - mind-mind kifelé indított 
kapcsolat) . Vannak azonban olyan szolgáltatások - és ilyen pél- 
dául az IRC is - amit nem vehetünk igénybe, ha a számítógépünk 
nem válaszol bizonyos külső kérdésekre. Nincs más teendőnk, 
mint kiütni a tűzfalból néhány téglát... csak az a kérdés, milyen 
téglákat, és hogyan? j 

Mindenekelőtt, bizonyosodjunk meg róla, hogy a problémánkat 
biztosan a tűzfal okozza-e. Az Internetcsatlakozás ikonján a 
tűzfal jelenlétét kis lakat jelzi. 
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i Fie Edit View  Favorites 
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! Address [(É) Network Connections 











Tools Advanced Help 
56X4DÖXID 








Network Tasks 


Create a new connection 


2 Set up a home or small 
5 office network 


See Also 


5 Ha az ikon jobb felső sarkában látható a kis lakat, a há- 
lózati kapcsolatot az ICF vigyázza 


Első lépésként a kapcsolat tulajdonságlapján kapcsoljuk ki a 
személyes tűzfalat, majd csatlakozzunk újra az Internetre. 


Le zá Re Ned lé] zata 
( General [/ Options [/ Security [/ Networking [ Advanced 
Intemet Connection Firewall 


tzeéss my computer and network by limiting or preventing 





:cess to this computer from the Internet 
Leam more about Internet Connection Firewall. 


a A tűzfalat az Internetkapcsolat tulajdonságlapjának 
Advanced oldalán kapcsolhatjuk ki-be 


Ha kikapcsolt tűzfallal működik a kívánt dolog, bekapcsolt tűz- 
fallal pedig nem, akkor érdemes meglesni, hogy pontosan mit 
szűr ki az ICF. Ehhez kapcsoljuk be újra a tűzfalat, majd a 
,Settings" gombra kattintva nyissuk meg az ICF beállításait tar- 
talmazó dialógusablakot. 


Advanced Settings 





Services ! Security Logging 
Logging Options: 
Log dropped packets 


og successful connections 


Log file options: 


Name: 
C-AWINDOWSApfirewall.log 


























Itt válasszuk ki a ,Log dropped packets" opciót, állítsuk be a 
logfájl kívánt nevét, majd csatlakozzunk újra az Internetre, és 
próbálkozzunk. Néhány sikertelen próbálkozás után keressük 
meg a naplófájlt és nézzük meg, milyen csomagok érkeztek 
esetleg, amit a tűzfalunk visszautasított: 
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MEZ EE] 


DROP TCP sss.sss. 
DROP TCP SSS.SSS. 
DROP TCP sss.SSS. 
DROP TCP SSS.SSS. 
DROP TCP ss5.SSS. 
DROP TCP SS5.SSS.SS: 
DROP TCP sss. 

DROP TCP sss. 
DROP TCP sss. 
DROP TCP sss. 
DROP TCP ssS. 
DROP TCP sss. 
DROP TCP sss. 
145 DROP TCP SSS.SS5.SSS. 





a A tűzfalnaplóban látszik, hogy az ICF milyen csomagokat 
utasított vissza 


A naplófájl oszlopaiból kiderül, hogy honnan (sss.sss.sss.s5ss), és 
milyen címre (ccc.ccc.ccc.ccc) tartott az elutasított csomag. Ha 
a ccc.ccc.ccc.ccc a saját IP címünk, akkor a csomag bejövő tí- 
pusú volt. Ellenőrizzük azért a túloldal IP címét is, nehogy vé- 
letlenül rossz kapukat nyissunk ki. A bejövő csomagoknál a 
beérkező (cél, azaz destination) port címe a lényeges, ezt a ka- 
put kell kinyitnunk, hogy a csomagok meg is érkezzenek hoz- 
zánk. Látható, hogy az esetünkben elfogott csomagok a 113-as 
portra érkeztek (ez az úgynevezett AUTH, más néven IdentD pro- 
tokoll) - az IRC-hez ez tényleg kell. 


TETT 





( Seres [decz Loggro [707] Seices (Seculy Loggna [TEMP 





Select the seryces unrn on yon network that intemet users can. 
Sermcer 

DD FTP Sever 

[DJ intemet Mal Access Pioiacol Versan 3 0MAPJI 

1D internet Mad Access Protocol Verson 4 OMAPAJ 

(TI irtemet Mad Server SMTPI 


l Name ar1P ada for examole 192.168.012) of the 
! JD PontOtsze Prctozatverson 3(POP2JI ! TAVAK 


hostng this service on you netmodk 


ID Remote Desktop Í ee ásás —— —— 


! JD Svazeweb Server HTTPS) 
(DJ Telnet Server 
JD web Server NATTPI 











Eternal Pot emrt bet Óda árát: 
] ore Our 








5 A beengedett-publikált szolgáltatások listája 


Az ICF lehetővé teszi, hogy a tűzfal mögött, a saját hálózatunkon 
- vagy akár a tűzfalat futtató gépen - található szolgáltatásokat 
tegyünk közzé az Internet felé. Ha be akarunk engedni valamilyen 
hálózati forgalmat, nincs más dolgunk tehát, mint publikálni az 
adott szolgáltatást - esetünkben nyissuk meg az ICF tulajdonság- 
lapját, majd vegyünk fel (és engedélyezzünk) egy új bejövő pro- 
tokollt a naplóból kilesett porton. A belső szolgáltatás IP címét 
pedig állítsuk a saját gépünkre - a 127.0.0.1 IP cím tökéletesen 
megfelel a célra. A kapcsolat újraindítása után az ICF be fogja en- 
gedni az adott portra érkező hálózati forgalmat. 





A cikkben szereplő URL-ek: 
[1] http://msdownload.netacademia.net/info.asp?prid-187 


ZBOZ. 02. 


Nomádélet a XXI. 6. 


században: 


mobil IP 


Az emberi szabadságvágy egyik ősidők óta jelenlevő megnyilvánulási formája a helyváltozta- 
tás, illetve a cselekvés minőségét (kényelem, sebesség stb.) is figyelembevevő mobilitás. 
Amit a honfoglaló őseinknek a lovak és szekerek jelentettek, azt a XX. század 

embere számára az autó, a vonat, a repülő testesítette meg. Az utazás ma már 

az egyszerű halandók mindennapi életének is részévé vált. 


A kommunikáció fejlődése mindezek mellett egyre meghatározób- 
ban vesz részt a mobilitás fogalmának alakulásában. A mobilitás- 
nak ez az aspektusa azt kívánja, hogy számítástechnikai és kom- 
munikációs szempontból mindenütt , otthon" érezzük magunkat. 
Én például minden macera nélkül szeretnék elektronikus képesla- 
pot küldeni ismerőseimnek, amint szabadságomat töltöm a 
Rivierán (főleg ezt szeretném :-) , vagy egy külföldi vállalatnál tett 
látogatás során is jó lenne a saját vállalatom csoportmunka-rend- 
szérét, belső állományait használni, pontosan úgy, mintha a he- 
lyemen ülnék. Az Internet hálózati protokollja ebben komoly gá- 
tat jelent, hiszen odaláncol bennünket, ahol kapjuk az IP címet. 
Folyton azt halljuk, hogy az internetes és a mobil világ konver- 
gál. Az alkotók dicséretére váljék, a mobilosok az IP mellett 
döntöttek. Ha a víziók valóra válnak, akkor a közeljövőben a 
számítógépek és a mobiltelefonok párosításából születő kütyük 
milliói árasztják el a világot és a világhálót. Ahány gép, annyi 
IP cím, így az IPv4-től azonnal el is búcsúzhatunk (hiába hirde- 
ti a 2002-es RFC, hogy támogatja a mobilitást) , jöhet az IPv6. 
Önmagában ezzel sem válik az IP cím hordozhatóvá, de a terve- 
zők tanultak az elődök hibáiból, és flexibilisebb protokollt tervez- 
tek, amely igény szerint bővíthető. Ennek megfelelően léteznek 
mobilIP kiterjesztések is (lásd [1]). Az alapkoncepció szerint egy 
Home Agent-nek (HA) nevezett kiszolgáló felelős hollétünk nyil- 
vántartásáért. Idegenben kapunk egy ideiglenes címet (a DHCP 
már része lett az IPv6-nak) , majd jelentjük a HA-nak, hogy mos- 
tantól ide (Care-of-Address - CoA) küldje a csomagjainkat. Sőt, a 
HA olyan rendes, hogy szól a velem (Mobil Node - MN) éppen kap- 
csolatban lévő gépnek (Correspondent Node - CN), hogy egyből az 
új helyemre küldözgesse amit akar, ne kelljen szegény IP csoma- 
goknak feleslegesen ekkora utat megtennie (triangular routing), 
aztán meg azon szégyenkeznie, hogy zabálja a sávszélességet ott, 
ahol egyébként lennie sem kellene. Mindezt egyszerűen csak Mo- 
bil IP-nek, vagy még rövidebben MIP-nek hívják. 

Semmi és senki sem lehet tökéletes, miért éppen a MIP és az 
IETF lenne az? Vegyünk egy olyan forgalmas helyet, ahol a cel- 
lák kicsik, és így a határaik közel esnek egymáshoz. Ez annyit je- 
lent, hogy kütyünk mozgás közben gyakran vált IP címet. Most 
már tudjuk, hogy ilyen esetben szükséges egy üzenetváltás a HA- 
val, ami ily módon értesül arról, hogy nem bírunk egy helyben 
maradni. Ekkor pont a kisebb kapacitású vonalakat fogjuk terhel- 
ni, és ez cseppet sem szerencsés. Egy újabb szereplő (Mobility 
Anchor Point - MAP) felbukkanása azonban véget vet a pazarlás- 
nak. A MAP több hálózatért felelős, és a HA válláról mindaddig 
leveszi a terhet, amíg a felügyelete alatt lévő területet nem 
hagyjuk el. Addig csak neki tartozunk bejelentési kötelezettség- 
gel. A CoA ekkor önmagában már kevés, hiszen kell egy olyan 
cím, ami a CN és a HA számára változatlan, míg én a MAP tarto- 
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mányában többször is címet változtathatok. Előbbi a MAP tarto- 
mányára jellemző (Regional Care-of-Address — RCoA), míg az 
utóbbi annak a hálózatnak egy címe amelyikben éppen tartózko- 
dom (on-Link Care-of-Address — LCoA). Mivel ez már jóval több a 
MIP-nél, hozzátettek egy H betűt (Hierarchical Mobile IP -— 
HMIP), ami a rendszer hierarchikus felépítését hivatott jelezni. 
Először kissé csalódottan vettem tudomásul, hogy míg a nagy te- 
lekommunikációs cégek esetenként már az IETF draft megjelené- 
se előtt elkészülnek az ahhoz tartozó fejlesztéssel, addig a Micro- 
softnak (publikus) HMIP implementációja egyáltalán nincs, és a 
MIP-ből is csak egy viszonylag régi (majdnem 1 éves, két verzió- 
val ezelőtti) draftnak megfelelő programjuk van. De lássuk be, a 
Microsoft nem telekommunikációs cég, így ne várjuk el egy tőlük 
még kissé távolabb eső területen is az élen járást. Mivel a (H)MIP 
az elkövetkező néhány évben még biztosan nem jelent majd ko- 
moly üzletet, a fejlesztést a Lancaster University lelkes ifjúságá- 
ra bízták. Néhány egyetemista fejleszti a kódot, a Microsoft és az 
egyetem közötti együttműködést fedő LandMARC (Lancaster and 
Microsoft Active Research Collaboration) projekt keretében. A 
program és a dokumentáció letölthető a [2] címről. (Három gép 
kell hozzá: MN, HA, CN!) 
Talán nem tartozik szorosan a tárgyhoz, de azért is felmentést 
adok az MS-nek a fejlesztési hátrányért, mert a szabványok, helye- 
sebben ajánlások tervezetei (IETF draft) minősíthetetlen állapot- 
ban vannak. A MIP több éves csiszolgatás után még mindig csak 
(helyesírási és hivatkozási hibáktól sem mentes) draft, abból vi- 
szont már a 15., és áprilisban várható a még mindig nem végleges 
16. változat. Konszenzus nincs, és élénk vita dúl a biztonsági kér- 
dések körül. A HMIP draft 4. változatába olyan hiba is becsúszott, 
amitől a protokoll nem is működhetett volna. Elgondolkodtató, 
hogy az erősen bürokrata vonásokat mutató IETF alkalmas-e még 
egyáltalán arra, hogy az Internet számára szabványokat dolgozzon 
ki. Egyes cégek, talán ráunva a szektorban nehezen tolerálható 
tempóra, saját protokollok kifejlesztésébe kezdtek. Az iparág hely- 
zete tehát - tömören szólva - divergensen konvergens. 
A számítástechnika és a mobil világ találkozása alaposan össze- 
kuszálta a már-már kristálytisztán kirajzolódó trendeket. Fogjuk 
fel azonban úgy, hogy egy olyan korban élünk, amely egyszerre 
tárja fel előttünk szakmánk szép és kevésbé szép oldalát. Egy 
biztos: IP goes mobile! 

Zacco 


[1] http://www.ietf.org/html.charters/mobileip-charter.html 
[2] http://research.microsoft.com/programs/europe/project 
s/MIPv6.asp 
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Rendezvénynaptár 


2002 tavaszán is folytatódik a TechNet Szemináriumok sorozata. 

A Microsoft Magyarország rendszermérnökei és vendégeik az előadások során áttekintik 

a kereskedelmi webhelyek biztonságát növelő technológiákat; kitérnek arra, hogy a Windows 
platform milyen eszközökkel segíti a vállalati webes alkalmazások fejlesztését; betekintést 
adnak az SOL adatbázisok adminisztrációjába, valamint ismertetik a hamarosan 

megjelenő Windows .NET Server és Project 2002 újdonságait. Mindezt természetesen 

a jól ismert , 10099 technológia, 090 marketing" szabály betartásával teszik. 


A következő félév rendezvényei: 

2002. 03. 06.: Windows alapú webes alkalmazások 

A webalapú technológiák terjedése a vállalati alkalmazások körében is tapasztalható: egyre több ilyen alkalmazás jelenik meg mind 
belső, mind külső célokra kifejlesztve. 

Az előadás áttekinti a Windows 2000 és a Windows XP platform azon elemeit, melyek segítségével egyszerűen és olcsón készíthe- 
tünk ilyen alkalmazásokat. Kitér a Windows-platformon elérhető ingyenes alkalmazásfejlesztő eszközökre (.NET Framework, parancs- 
nyelvi eszközök) , adatbáziskezelőkre (Microsoft Destop Engine), valamint néhány biztonsági és licencelési kérdésre. 


2002. 03. 20.: Biztonságos Windows 

A Windows 2000 Server operációs rendszert széleskörűen használják az Interneten. Méginkább igaz ez a kereskedelmi webhelyekre. 
A biztonság kérdése már a tervezés során is rendkívül fontos szerepet játszik. Az előadás során ismertetjük a Microsoft által megal- 
kotott Solution Offering termékcsoport részét képező, az Interneten üzemelő adatközpontok (Internet Datacenter - IDC) számára el- 
tervezett hálózati architektúrát, és áttekintjük az üzemeltetés során felmerülő biztonsági kérdéseket. Szó lesz a 2001 őszén meghir- 
detett stratégiai technológia védelmi programról (STPP) is, amely a Windows 2000 alapú rendszerek biztonságossá tételét és szin- 
ten tartását célozza meg. Megmutatjuk a program részeként elérhető IIS Lockdown Tool-t és a Microsoft Security Tool Kit CD-t. 


2002. 04. 03.: Vállalati szintű projektmenedzsment 

Az összetett, sokszereplős projektek informatikai támogatása komplex feladat, érinti a hálózati és kommunikációs infrastruktúrát, 
a kiszolgáló- és ügyféloldali alkalmazásokat és a rendszerfelügyeletet is. Az előadásban a hamarosan megjelenő Project 2002 ter- 
mékcsalád felhasználásával bemutatjuk, hogyan alakítható ki és tartható kézben a projektek tervezéséhez, a kapcsolódó anyagok 
tárolásához, a résztvevők kommunikációjához, illetve a követéshez és elemzéshez szükséges környezet. Ismertetjük a fájl- és 
intranetkiszolgálókkal, a levelezőrendszerrel, az adatkezelő és -elemző rendszerekkel való kapcsolódást. Külön figyelmet szentelünk 
a nagyvállalatok projektkezelési igényeinek, így például a szervezeti szintű erőforrásmenedzsment problémakörének, és bemutat- 
juk az ezekre választ adó új Project Server terméket. 


2002. 04. 17.: Üzemeltetői Konferencia 

A hagyományokhoz híven a 2002 tavaszi üzemeltető konferencián is a Microsoft rendszerek üzemeltetéséhez szeretnénk segítsé- 
get nyújtani. A tervezett előadások témái között megtalálható a Windows 2000 és a Windows XP egymás mellett élésének zökke- 
nőmentessé tétele, Az SOL és Exchange szerverek üzemeltetésének fogásai és természetesen az elmaradhatatlan internetes bizton- 
sággal foglalkozó előadás is. Sort kerítünk a virtuális magánhálózatok kialakításának üzemeltetőket érintő kérdéseire és a Windows 
alapú rendszereket összekötő hálózatokkal kapcsolatos napi feladatokra. Ezúttal is fogunk érdekes és néha meglepő dolgokról be- 
szélni és megpróbáljuk az őszi konferencián a résztvevők által kért témákat is az előadások sorába iktatni. 


2002. 05. 08.: A Windows.NET Server technikai újdonságai 

A Windows 2000 Server-t követő új kiszolgálócsalád, a Windows .NET Server szolgáltatásait ezúttal nem tárgyaljuk témakörönként 
külön előadásokon, ez az áttekintő előadás elsősorban a Windows 2000-hez képest történt fejlesztésekre és újdonságokra koncent- 
rál. Ismertetjük az Active Directory címtárszolgáltatás új funkcióit, a vegyes Windows 2000/Windows .NET címtár környezetek hasz- 
nálatát, az új csoportos házirendeket, a rendszerfelügyeleti újdonságokat. Terítékre kerül az Internet Information Services 6.0 tel- 
jesen átalakított architektúrája, a kibővült funkcionalitású terminálszolgáltatás. Tárgyaljuk a biztonsággal kapcsolatos fejlesztése- 
ket, kitérve a PKI infrastruktúrával kapcsolatos újdonságokra, a hálózatkezelés terén pedig a Windows XP munkaállomásban nem 
szereplő kiszolgálóoldali kibővült szolgáltatásokat érintjük. 

A TechNet-előadások a már megszokott helyszínen, a Lurdy Házban található Hollywood Multiplex moziban ,játszódnak", míg az 
Üzemeltetői Konferencia helyszínét később tesszük közzé. 


Az egyes előadásokkal kapcsolatos részletes információkat - tervezett napirend, előadók, stb.- a rendezvényeket megelőző hetek- 
ben tesszük közzé rendezvénynaptárunkban. Ugyanitt elérhetők a jelentkezési lapok, illetve - a rendezvényeket követően - a be- 
mutatók PowerPoint diái is. 

http://www.microsoft.com/hun/events/technet.asp 
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" Felkészülés 
valami komolyabbra! 


A tavaszi pezsgést a magunk részéről mi is szeretnénk élénkebbé tenni. 
Beindítjuk Ugróiskola előadássorozatunkat, ahol azonnal hasznosítható 
ismeretanyag átadására törekszünk. Aki beugrik hozzánk, az úgy jut to- 
vább élete következő mezőjére, hogy valami hasznos szerszám-eljárás 
birtokába jutott. 


AT [d T e te ea ea STATE 
1. Ne raboljuk egymás idejét! 
Egy-egy alkalom maximum 2 óra hosszúságú. Ez azt jelenti, hogy: 


nem veszünk el egy fél munkanapot sem az életéből 
€ ami nem érdekli a sorozatból, azon nem vesz részt 
nem kell szólnia senkinek, engedélyt kérnie senkitől, hogy tanulni megy 
(anyagi támogatást sem kell kérnie főnökétől, lásd alább) 
LILLE LETT ET LA LT ÉT s 


2. Tapasztalat, tapasztalat, tapasztalat! 
Amit kézzel nem tudunk megfogni, az nem is létezik. Ha ez tanulnivaló, akkor gyakorlás 
híján elillan. Épp ezért: 


le ád Eegen tet [ge e ege ete LETT ANT ILS ae] 
tantermünkben 

az egyes témakörökhöz nyomtatott háttéranyag áll rendelkezésre 

felkészült oktatóink segítenek túljutni a buktatókon 





Windows 2000 Scripting ugróiskola - felkészülés valami komolyabbra 





Időpont 














A Windows Scripting Host és a scriptnyelvek Scriptek: az egyszerűtől a bonyolultig. Áplris 5, 

(VBScript, JavaScript) Hello worldtól a scriptvírusokig. péntek 

Címtárkezelés. Active Directory Services Felhasználók, csoportok tömeges létrehozása, Április 12, 

Interface (ADSI) módosítása, mozgatása az AD hierarchiában. péntek 
Jelszóállítás. 

Levelezés. Collaborative Database Objects (CDO) Automatikus levélküldés bizonyos rendszeresemények Április 19, 
(rendszerindítás, service leállása stb.) hatására, péntek 
levél fogadása. 

Rendszerfelügyelet. Windows Management A rendszer állapotának lekérdezése, megjelenítése Április 26, 

Instrumentation (WMI) weblapon, (táv)felügyeleti parancsfájlok készítése. péntek 

Adatbáziskezelés. ActiveX Database Objects Adatbázis tartalmának lekérdezése, megjelenítése. Április 30, 
Adatmódosítás. Tárolt eljárások hívása kedd 


Helyszín: CEU Konferenciaközpont, Kerepesi út 87. 
Kezdési időpont: reggel 9 óra. 

Jelentkezés: www.netacademia.net/ugrosuli 

A rendezvényeket számítógépekkel felszerelt 


tantermekben tartjuk, így minden 
ismeret kipróbálható, begyakorolható. 


VIMJUVOV 
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Következő számunk tartalmából 


RIS 
Az utolsó részben megnézzük hogyan lehet több telephely esetén a RIS kiszolgálókat szinkronban tartani, 
valamint az Ügyféltelepítő Varázsló (CIW) képernyőket fogjuk átszabni. 


Ww2k 
Járjuk be együtt a Windows 2000 rétegzett hálózati architektúráját! Hogyan kapcsolódnak egymáshoz a 
komponensek? Hány szolgáltatás áll, ha ,at least one service failed to start"? 


w2k 

Dinamikus DNS 

A Windows 2000 Active Directory lelke a DNS - és az sem árt, ha az a DNS kiszolgáló bizony képes a dinamiku- 
san érkező bejegyzéskérelmek fogadására és feldolgozására. Cikkünkben a DDNS protokollt, valamint a Windows 
2000 DHCP kiszolgáló, a Windows 2000 kliensek, valamint a DNS kiszolgáló együttműködését mutatjuk be. 


Farkasokkal táncoló 
Ezúttal is alapozó munkát végzünk, folytatjuk az ismerkedést az erőforrástípusokkal. Nem ígérhetek könnyű olvas- 
mányt: minden típusnak megvan a maga bogara, és nem árt ezekkel tisztában lenni, mielőtt használni akarjuk őket. 


Jog 

Az elektronikus kereskedelem körén túl - amint azt a már elemzett jogalkotói szándék is mutatja - az 
Internet számos egyéb kérdésére próbál meg jogalkotói választ adni a törvény. Így az amerikai és európai 
szabályozással összhangban rendezi a szolgáltatók egyes tevékenysége esetén felmerülő felelősség kérdé- 
sét, továbbá a szerzői jogi jogsérelem esetére bevezeti a notice and take down eljárást. 


:NET 
Az alaptípusokat tovább boncolgatjuk, megnézzük mik azok az interfészek, miért fontosak számunkra, mire 
valók a delegate-ek, és ehhez kapcsolódóan hogyan működik a .NET natív eseménykezelése? 


XML 
Folytatjuk a relációs adatbázisok és az xml világ közötti átjárást. Tovább boncolgatjuk a DataSet osztály 
szolgáltatásait, és megszemlélünk egy valódi virtuózt, XmIDataDocument objektumot. 


ASP Suli 

Exchange postaláda elérése mobiltelefonon? Nem gond! ASP Sulinkban még egy cikk erejéig maradunk a mo- 
bil eszközök programozásánál. A következő számban a CDO for Exchange 2000 és az ADO segítségével meg- 
valósítjuk az Outlook Wap Access szuperkompakt változatát. 


Exchange - új sorozat 

Méltatlanul elfeledett termékre térünk vissza: az Exchange Serverre. Nem a felhasználók feledték el, hanem 
mi nem törődtünk vele ezidáig megfelelően. Most útjára indítjuk Exchange Server sorozatunkat, mely a te- 
lepítéstől kezdve végigvezet a termék használatának rejtelmein. 


RAS 

Az útválasztási protokollok sorában a RIP-nál tartottunk. Kis hálózatokon jó lehet a RIP, de korábban is- 
mertetett korlátai (különösen a lassú konvergencia, valamint a hurokgyanú) miatt nem mindenütt használ- 
ható. Ezzel szemben az OSPF szinte mindent tud már. Nem útvonaltáblákat, hanem egy úgynevezett Link 
State Table állapottábla sorait küldi szét partnereinek, amelyek tetszőlegesen bonyolult hálózatban megta- 
lálják a pillanatnyilag legolcsóbb utat. 
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Él as - 2 sz CÍMZETT: NETACADEMIA KFT. FAX 
zik FAXSZÁM: (1) 261-7145 

Tisztelt Olvasónk! 

Lapunk hírlapárusi forgalomba nem kerül, ezért ha kíváncsi megkezdett sorozataink folytatására, kérjük töltse ki és juttassa el hozzánk az alábbi megrendelőlapot. Előfizetőinket 


szeretettel várjuk Mesterkurzusainkon. Klubtagjaink kedvezményesen vehetnek részt konferenciáinkon, tanfolyamainkon stb. 
Kérjük töltse ki ezt az előfizetési szelvényt és faxolja el az (1) 261-7145-ös faxszámra. 





.. , . tech.net magazin havonta csak I Minden előfizetőnk 
VÉ 1 Íltattig . tech.net tipp viszont ; megkapta Magyarország 
3 Vé 


tg 6 egyetlen informatikai asz- 
net tali naptárát, csak Önnek 


nincs! Ilyen körülmények 
között nem lehet nor- 
málisan dolgozni! Hisz 
nem jut hozzá a hét tippjé- 
. hez! Fizessen elő MOST, 
97. snek val mert 2002 első száz 

tn fak előizetője még hozzájuthat 
a naptárhoz! 


Bugvadászat! 

Vigyázat! A naptár bugos! 
A hibák megtalálói 
ajándékot kapnak! 








Előfizetem a tech.net magazint:  ...példányban egy évre (14.784 Ft) 


. . példányban fél évre (7.392 Ft) 


Az előfizetés kezdete:...... Jee 





SMODUuIM Wim 65UDjIom 


Fizetés módja: il csekken (postán küldjük) L] átutalással 


Amennyiben a számlázási cím nem egyezik meg a szállítási címmel, kérjük 


az alábbi részt is töltse ki! 
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Számlázási cím: Szállítási cím: 


NETACADEMIA 


A LEGJOBBAKAT TANÍTJUK. 


Bugos naptár SP1 


Mint azt bizonyára többen észrevették, ezévi naptárunk - a szoftveriparban talán nem váratlanul — hibásan került az Önök 
kezébe. Felelősségünket vállalva ezúton kibocsátjuk hozzá első javítócsomagunkat. Az eddig észlelt hibák közül az egyik 


legsúlyosabbat javítjuk ezzel a csomaggal: en 
TÉTETETT INNÉT ETT TT TITI TTTTTTTTI 
term netÜnp Hveste [4 
E matricával a hiba 


könnyen korrigálható! 











— sel 
Április hónapban nincs negyedike?! 


A bugvadász verseny természetesen tovább folytatódik, a naptár korántsem vált hibátlanná. Az összes hiba 
felfedezéséért értékes jutalmat adunk! Megfejtését erre a címre várjuk: infor(rdonetacademia.net 


infoBbYTE 


A távközlési piac liberalizálása és a mobiltelefóniában várható 
generációváltás érdekegyeztetési törekvéseiről tudósít ez a rovat. 


A Tönap vezető cikke új SZADGIÉBMSEB megoldásokról. 
Külfödi hírek, kitekintés; 


Az Informatikai Kormánybáztosság 2001— 2002-ben 
összesen 36 különféle programot koordinál. Az információs 
társadalom kiépítésének lépcsőfokai ezek. 


Az Inforum célja, hogy párbeszédet folytasson a szakma és a 
kormányzat között. Aktív szerepet vállalt a szerzői jogi, az 


egységes hírközlési és az elektronikus kereskedelmi törvény 
megalkotásában. 


l ) XI i 1 
Ebben a rovatban nem elsősorban a technológiára, hanem a 
megvalósult projektekre, az EU-kompatibilitás kérdéskörére, 


pályázatokra koncentrálunk. 


Tel.: 


PANNON SUPPORT 


RENDSZERHÁZ Kft. 


Komplett, korszerű kisvállalati megoldás! 


IBM xSeries 200 Server (107 


Inter Pentium PIlII866 Mhz 
128MByte RAM (max. 1.5 GB) 
18.2 Gbyte SCSI HDD 


Adaptec 29160LP 1 
FDD, CD 10/100 3 cia 


IBM NetVista A21 (PBD38HN 


Inter Pentium C900 Mhz, 128MB RAM 
20 Gbyte HDD, CD, 10/100 ethernet 
Ms Windows 2000 Pro. Magyar, 


3 év garancia ő 


Cel.-os munkaállomásokkal: 


ét munkaállomásokkal: 2.490. 400, -t 
1 Hijesos munkaállomásokkal: 1. 649. §00,- x 


P4-es munkaállomásokkal: 


"A felüntetett ár tartalmazza: 
- 1db IBM xSeries 200Server; MS Small Business Server 2000 
- 5 felhasználó számára a szerver hozzáférést 


269-2233, 269-2797 Tel.: 


jea b RL tá er bt J 
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Az infopen.hu webmagazin és az infoBYTE közös rovata, 
kifejezetten IT vezetők számára. A rovat egy aktív CIO-val 
készült átfogó interjúval indul, amelyet stratégiai jellegű 
technológiai áttekintések, szakcikkek követnek. A rovat 
hangsúlyos részei a vállalati IT megoldásokat bemutató 
esettanulmányok, de interjúk, konferenciatudósítások 
formájában a piac meghatározó megoldásszállító cégeinek üzleti 
és termékstratégiájának bemutatása is helyet kap. 


Tapasztalatok szerint három-négy évente változtatunk mi, 
informatikusok állást, szakmát vagy szakirányt, és ez a szám a 
jövő évtizedekben valószínűleg csökkenni fog. 


E rovatunkban olvasóink nevében és helyett Novell szakértőket 
kérdez a szerző. 


A NetAcademia-féle mélyvíz-tanfolyamokra iratkozhatnak be 
azon olvasóink, akik Dr. Watson nyomában járnak. 


Hardver- és szoftvertesztek röviden, velősen. 


Sokakat érdeklő CPULújdonágok mélységei 
a fejlesztéshez közel álló szakértők tollából, 


Kérjen mintapéldányt: minta€infobyte.hu 


382-0313, 382-0O ts 


Bp 1119. Etele út 10. Fsz.1. F: 20. 


Infoopsr.hu 


Microsoft 


CERTIFIED 


Windows : 
SOL Server 2000, ISA Server, 
Health Monitor, Managment Console, 


Windows FAX és Modem megosztási, 
szolgáltatás 


ird Edition 


Válasszon! 
IBM NetVista A22p (PDI 


Inter Pentium IV 1,5Ghz 128MB RAM 
20 Gbyte HDD, CD, 10/100 eth 
Ms Windows 2000 Pro. Magyar, 


3 év garancia 
1.419.§00,-" 




















3.333.110,-" 


- 5db IBM munkaállomást (operációs rendszerrel, monitorral, billentyűzettel, egérrel) 

Igény esetén a rendszer megvásárlásához, lizing konstrukció kialakításában is segítünk! 

Január és február hónapban minden 1008 Ft feletti Microsoft és IBM terméket vásárlók között 

IBM WorPadt-et sorsolunk ki! Áraink a 2596-os ÁFA-t nem tartalmazzák! Az árváltozás jogát fenntartjuk! 
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Íkód  Megnezezés s j Hi —] Időt. Ár N MS Kezdési időpontok 
! 16 5i 8.) Zoktr4.])  okt.8.! szija ie 
1560 Updating Support Skills to Windows 2000 S5nap 1390000 ás! Al ess ő ék e. 
! nov: 19.! nov. 12.) "növ:5.! nov.12.! Okt. ; 










okt.45.! "okt. 8.) Fokt-1.! okt. 8.) okt 1 
nov. 19.! nov.12.! mov.5.! nov. 12.) ökt. 15.! 
9.! "dec. 3.! fov:26. ac. 3.) nov. 19.] 
.] [an.7.! dec:17. h [jan. 7. hdec. 10.) 


2152 "Implementing Windows 2000 Server and Professional 5 nap 125000 





[es Implementing Windows 2000 Network Infrastructure , 5 nap 125 000/ 

















12154 "Implementing Windows 2000 Directory Services 5 nap 125 0007 
1572 !Implementing, Administering Exchange 2000 5 nap 139000 9.! "dec.3.! nov.26.! dec.3.! nov.19.! 26. 
fi ij Í A d 
1561 ! Designing Windows 2000 Directory Services 3nap 95000 5 i, 8—— al KN a tune 
decs40.! ! jan. 7.1-dec.12.!) "jan.7. dec.10.! (. déceir. 
2159 ! Deploying and Managing ISA Server 2000 2nap 790000 láz tl Í vb ll) ESEM ú 7T 
ovábbi tanfolyamokról és időpontokró djön szervezőinkné s észletes tájékoztatót küldünk 
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